In his keynote, Josh Boehm, an associate attorney at Perkins Coie, discussed the blurred lines between tokenized goods and services and tokenized financial returns. Referencing the Securities and Exchange Commission's DAO report, Boehm explained the Howey Test, the agency's method for determining whether an instrument qualifies as a security. He indicated that function typically outweighs form, and most tokens usually satisfy the first two prongs of the test – that is, most tokens (i) constitute an investment of money (ii) in a common enterprise.
The ability to avoid securities designation more often resides in the third and fourth criteria, which are that the investment is made with (iii) a reasonable expectation of profits (iv) derived from the management efforts of others. Boehm also noted the potential for capital appreciation, which may qualify under securities law – though it remains ambiguous. In analyzing a token, Boehm explained, it's likely that the legal system will closely examine the terms of sale and services. He strongly encouraged founders and projects undertaking token offerings to ensure that their terms of agreement and accompanying documentation were "robust."
Even in the utility token context, Boehm said, the "follow through" is key. That is to say, if a project purports to provide some good or service and has acquired capital for that express purpose, then it is incumbent upon the team members to deliver on their promise.
A second keynote was delivered by Karl Floersch, a software engineer from ConsenSys who is working as part of the Ethereum Foundation on Casper proof-of-stake. In a quirky presentation filled with memes and developer shoutouts, Floersch gave an overview of slashing, the penalization mechanism that is being considered for Casper.
In order to participate in block validation in Casper, miners must stake some Ether. If a bad actor tries to compromise the network, his staked Ether will be slashed, or burned, meaning that it will be eliminated from the total supply. This has economic implications for the appreciation of remaining Ether, but it also means that when the slashing occurs and individuals lose their Ether, the cost to conduct an attack is reduced overall.
Later in the day, Vlad Zamfir elaborated upon Floersch's points while discussing the "Cryptoeconomics of Casper." Zamfir talked about how to "maximize the cost" of an attack to make it economically unjustifiable. For now, the protocol remains under development.
In "The Meshcash Framework: Tortoise and Hares Consensus," Tal Moran, a faculty member at the Interdisciplinary Center Herzliya, proposed a two-part blockchain. This would have a slower layer (the tortoise), which gradually agreed on older blocks and a faster layer (the hare) to reach consensus for more recent blocks.
Up next was Ren Zhang, a researcher at the COSIC research group in Belgium. Zhang cheekily redefined the slogan for Bitcoin Unlimited, calling it "Bitcoin Unlimited: release the potential ... attacks." The basic problem is that the incentive structure for mining blocks without a size limitation is atrocious. Bitcoin Unlimited would allow players to equivocate and mine on separate chains to gain a disproportionate share of block rewards relative to their mining contributions. This is neither sustainable nor logical, so it doesn't really make sense why "BU," as it's called, has received even an ounce of legitimacy.
Philipp Jovanovic, a post-doctoral researcher from the Swiss Federal Institute of Technology Lausanne (EPFL) then presented on "Scalable Bias-Resistant Distributed Randomness." He proclaimed the importance of publicly verifiable randomness, citing failures like the draft lottery for the Vietnam War (in which people born in December were more likely to be drafted than those born in January). The major challenges for publicly verifiable randomness are trust and scale. He explained that even generating a random number through a decentralized process can prove challenging because the last person to contribute a number to the collection ultimately controls the overall output.
For example, if Alice declared that her number is 13, Bob declared that his number is 17, and then Carl declared that his number is 19, then that means Carl controlled the entire process. Carl knows that the sum of Alice and Bob's numbers was 30, so his contribution didn't really create a truly random number (49)
Even if everyone commits to their numbers in advance, that doesn't solve the problem of revelation. For example, if Bob and Carl reveal their numbers, but Alice doesn't really like what she sees, then Alice can choose to not participate. You can check out Phillip's slides here (fair warning: you might need a PhD to understand the later proposals).
The most insightful presentation of the day came from the CEO and co-founder of 21.co, Balaji Srinivasan. He beautifully explained the desperate need for measures of decentralization, suggesting that things "are only as decentralized as their least decentralized subset." Whether this means looking at clients, nodes, developers, exchanges, owners, or entirely different statistics, the cryptocurrency community needs to consider where centralization remains. Instead of injecting politics into the discussion, Srinivasan said, the community requires quantitative and agnostic approaches. Through his presentation, he successfully pushed forward discussion and encouraged people to begin debate on these sorts of measurements, so that the conversation is about how to measure. His well-reasoned philosophy prioritized engagement and meaningful discussion.
I hope I was able to shed a little bit of light on the presentations at CESC 2017 over the last two days. Each of the speakers was terrifically welcoming and managed to impart nuggets of wisdom, which will no doubt inspire countless hours of additional research. Bringing together intellectuals from around the world, Blockchain at Berkeley carried off an impressive and successful conference that has surely done a great service in advancing the cryptocurrency community and the study of cryptoeconomics.