A story has been circulating about China's recent move to begin regulating the way games display information about the drop rates of random loot. This PC Gamer article is a solid source of a summary, and if you want to read the original text it is available here.
I haven't been able to locate a full translation myself but the Google machine translation, plus the chatter floating around the internet, seems to make it clear that a blind box with random items that is available for a virtual currency must display the odds of the player obtaining each of the possible outcomes.
One interesting piece that I picked out is that this will require companies to record and provide actual data to show that the odds are the same as posted.
It will be interesting to see how granular the data must be. If cards are ranked common, rare, epic, and legendary, is displaying those percentages enough? How will the values be assessed? What is stopping a company from making a pool of 10,000 common cards, one of which is essential, and then saying you pull a common 50% of the time? Those odds sound good but really you are looking for the 1 in 10,000 from that 50%.
I'm also curious to see how the tension between virtual and real currency, as well as player selected vs. skill based awards plays out under this regulation. From what I can see from the machine translations, this is looking at cases where a player purchases a virtual currency with real currency and then is able to use that virtual currency to obtain items. But what if that virtual currency is available from in game actions? Additionally, will the extend to things like drop rates from monster kills? What if a game charges you $5 to fight a battle, and the monster can drop one of three possible items on defeat - does this require full explanation under this regulation?
Saturday, December 10, 2016
Friday, August 12, 2016
Academic Approach to Smart Contract Language
Barclays and the University College London recently published this linked academic paper on Smart Contracts and the need for formalized language. Interestingly enough, it is a good step in the right direction, as it seeks to normalize the current tension between Smart Contracts as automated computer code with the legal notion of a Contract as a formal agreement. It is a tough read but worthwhile for anyone interested in the topic.
I'm still digesting it, but one thing that stands out is the call (which I have seen repeated elsewhere) for a standardization of "Smart Contract" language (in both code and the legal meaning) as a way forward. While this is great in theory, I think it also is a red herring in turning "Smart Contracts" into an everyday form of business.
In a traditional paper and ink world, contract terms have a level of standardization that has arisen out of practice, however much is also open to interpretation. Additionally, under U.S. law there is a significant body of case law surrounding the various negotiation power of a contract. Does each side have equal power to negotiate? Who drafted the actual words, even if both approved in the end? Is this a take it or leave it contract, or can the terms be negotiated?
This is where the movement to standardize Smart Contract terms breaks down - even if a group were to come up with defined, standardized terms to be used in all Smart Contracts, it would still be conditioned upon both parties agreeing to use those pre-defined terms and not either a) a different set of pre-defined terms or b) negotiating the terms from scratch. Right away, you have opened yourself up to potential litigation on the terms.
This in and of itself shouldn't be a roadblock to further development, but a good, readily available analogy is to compare this to website terms and conditions. A "Smart Contract" for trading crypto currency based on other pre-defined values could use the standardized Smart Contract terms promulgated by a party, but this is no different than agreeing to the jurisdiction under which the contract terms are interpreted. Essentially, you have layered an additional jurisdictional requirement over the contract.
It is refreshing to see experts working to solve some of the fundamental problems, and taking a somewhat academic approach to do so, but it is clear that issues still exist and Smart Contracts remain in the realm of Automated Computer Code.
I'm still digesting it, but one thing that stands out is the call (which I have seen repeated elsewhere) for a standardization of "Smart Contract" language (in both code and the legal meaning) as a way forward. While this is great in theory, I think it also is a red herring in turning "Smart Contracts" into an everyday form of business.
In a traditional paper and ink world, contract terms have a level of standardization that has arisen out of practice, however much is also open to interpretation. Additionally, under U.S. law there is a significant body of case law surrounding the various negotiation power of a contract. Does each side have equal power to negotiate? Who drafted the actual words, even if both approved in the end? Is this a take it or leave it contract, or can the terms be negotiated?
This is where the movement to standardize Smart Contract terms breaks down - even if a group were to come up with defined, standardized terms to be used in all Smart Contracts, it would still be conditioned upon both parties agreeing to use those pre-defined terms and not either a) a different set of pre-defined terms or b) negotiating the terms from scratch. Right away, you have opened yourself up to potential litigation on the terms.
This in and of itself shouldn't be a roadblock to further development, but a good, readily available analogy is to compare this to website terms and conditions. A "Smart Contract" for trading crypto currency based on other pre-defined values could use the standardized Smart Contract terms promulgated by a party, but this is no different than agreeing to the jurisdiction under which the contract terms are interpreted. Essentially, you have layered an additional jurisdictional requirement over the contract.
It is refreshing to see experts working to solve some of the fundamental problems, and taking a somewhat academic approach to do so, but it is clear that issues still exist and Smart Contracts remain in the realm of Automated Computer Code.
Tuesday, July 12, 2016
Another Lawyer's Perspective on Smart Contracts (article and analysis)
Finally! An attorney who understands that "Smart Contract" is a terrible misnomer. This article about Smart Contracts by Selachii attorney Richard Howlett was refreshing to read, as I see so much written and discussed about Smart Contracts and how a few lines of computer code will revolutionize the world. Howlett makes insightful points regarding the difficulties faced with both complexity and grey areas in contracting. Complexity seems entirely solvable to me, it will just take time and effort to get there. I have no doubt that if Grand Theft Auto 5 can be coaxed into existence, someone can write a computer program that meets the complex needs of a contract.
The second issue, though, stems from what could be called the worst part of contracting - those grey areas. Howlett describes it as the "creativity and flexibility that can come only from real-life experience." This is true - contracts often are matters of interpretation and situational developments, and what works for one situation may not work for others. Ideally, though, a contract leaves no room for interpretation and has a definite answer for every situation. Whether this is possible or practical for human use, is another question, and strikes at why Smart Contracts as automated computer code leave some gaps between written agreements.
One area where I do disagree (at least slightly) with Howlett is in his objection surrounding the jurisdictional issues. He notes that there is no international internet law (a point I would somewhat dispute but that is a much larger discussion for another day) as well as the difficulties in selecting and determining the jurisdiction under which the contract will be interpreted. This is a standard clause (at least under an American legal theory) in every contract, and such a provision in contained in every click-thru license agreement. Jurisdictional provisions are in the terms associated with any payment processor, any online commercial transaction, and within the terms and conditions or acceptable use policies on any website. Why Howlett cannot imagine that a Smart Contract or Automated Computer Code couldn't (and wouldn't!) contain the same language is beyond me.
I'll grant him that even with jurisdictional language included, there remain significant legal challenges regarding choice of law, venue, interpretation, and enforcement.
Interestingly, he doesn't hit on my biggest concern regarding so called Smart Contracts or Automated Computer Code - the fact that they aren't in fact smart. A fundamental tenet of Contracts practice is that you do not waive your remedies in advance or by your failure to take a certain action. A smart contract, as commonly envisioned, does just this. A favorite example is for car rental - the idea being you use your blockchain identity to walk up to car, verify your identity, and then the "Smart Contract" automatically enables you to drive the car while charging you in accordance with the terms and conditions. In this scenario, let's say your payment method fails and the Smart Contract is set to revoke access to the car. Rather than the car rental agency having to send a breach notification, give you a time to cure, and then moving to restrict your further access without payment, instead the "Smart Contract" simply deducts what money it can from your account, stops the car, and says Have a Nice Day.
No where in this process can you challenge this under any circumstances until after the fact. There is no room for necessity (a chance to say, not be stranded in the middle of desert!), there is no chance to cure (by say, providing access to alternative forms of payment), there is no place for administrative errors to be corrected. In my view, this is a glaring oversight to calling automated computer code based on the blockchain Smart Contracts.
The second issue, though, stems from what could be called the worst part of contracting - those grey areas. Howlett describes it as the "creativity and flexibility that can come only from real-life experience." This is true - contracts often are matters of interpretation and situational developments, and what works for one situation may not work for others. Ideally, though, a contract leaves no room for interpretation and has a definite answer for every situation. Whether this is possible or practical for human use, is another question, and strikes at why Smart Contracts as automated computer code leave some gaps between written agreements.
One area where I do disagree (at least slightly) with Howlett is in his objection surrounding the jurisdictional issues. He notes that there is no international internet law (a point I would somewhat dispute but that is a much larger discussion for another day) as well as the difficulties in selecting and determining the jurisdiction under which the contract will be interpreted. This is a standard clause (at least under an American legal theory) in every contract, and such a provision in contained in every click-thru license agreement. Jurisdictional provisions are in the terms associated with any payment processor, any online commercial transaction, and within the terms and conditions or acceptable use policies on any website. Why Howlett cannot imagine that a Smart Contract or Automated Computer Code couldn't (and wouldn't!) contain the same language is beyond me.
I'll grant him that even with jurisdictional language included, there remain significant legal challenges regarding choice of law, venue, interpretation, and enforcement.
Interestingly, he doesn't hit on my biggest concern regarding so called Smart Contracts or Automated Computer Code - the fact that they aren't in fact smart. A fundamental tenet of Contracts practice is that you do not waive your remedies in advance or by your failure to take a certain action. A smart contract, as commonly envisioned, does just this. A favorite example is for car rental - the idea being you use your blockchain identity to walk up to car, verify your identity, and then the "Smart Contract" automatically enables you to drive the car while charging you in accordance with the terms and conditions. In this scenario, let's say your payment method fails and the Smart Contract is set to revoke access to the car. Rather than the car rental agency having to send a breach notification, give you a time to cure, and then moving to restrict your further access without payment, instead the "Smart Contract" simply deducts what money it can from your account, stops the car, and says Have a Nice Day.
No where in this process can you challenge this under any circumstances until after the fact. There is no room for necessity (a chance to say, not be stranded in the middle of desert!), there is no chance to cure (by say, providing access to alternative forms of payment), there is no place for administrative errors to be corrected. In my view, this is a glaring oversight to calling automated computer code based on the blockchain Smart Contracts.
Subscribe to:
Posts (Atom)