Blockchain Week madness! A slight delay on publishing Day 2 of CESC due to the many events and great talks - including an information-dense one from Vitalik. Props to Ronen Kirsch and the entire San Francisco Blockchain Week team for working with a last minute situation and pulling off the Four Seasons location, with a special shout for help from Forte co-founder Josh Williams.

Check out some highlights from Day 1, including side events and party listings.

If you are in the market for a job in blockchain, hope you made it to the Career Fair. There’s still time to participate in the DeFi Hackathon happening on Friday.

CESC was sold out but there are still a few tickets left for Epicenter (get 15% off with code ‘blockchaing’). Unfortunately, I will be traveling and unable to attend Epicenter this year, however Oct 31 and Nov 1 are being livestreamed and you can check out the stream with DLive here

Select Session Overviews

Kadenamint, Cosmos, and Pact: Universal Smart Contracts - Monica Quaintance, Kadena

Tuesday, October 29th, 2019 | 11:45am

Monica Quaintance, Head of Research at Kadena, spoke about the latest developments at Kadena and the benefits of the Pact smart contract language, which they hope will become the universal standard for smart contracts. Kadena is a massively parallelized Proof of Work public blockchain (they can also run private) which uses the Chainweb consensus protocol and runs the Pact smart contract language. They are soon going to be supporting integration with Cosmos/Tendermint (“Kadenamint”) and they are also going live for mining shortly. Much of the talk was diving into the differences and benefits of Pact, and novel ideas that can be built using these differences/benefits.

Why Pact? The goal is for non-engineers to be able to work with Pact, to make it human-readable and safe. Pact was created to be the world’s simplest, most user-friendly interface for writing robust code on the blockchain. We’ll discuss some of the main features of Pact here but for more comprehensive info, check out: https://pactlang.org/
Pact is effectively a database scripting language, customized for a blockchain execution environment. It is interpreted rather than compiled, so code on the chain is legible instead of in bytecode. There are descriptive error messages, contracts are upgradable, natively multisig, and have a built in governance function specifying complex access control
Turing Incomplete By Design - Pact is Turing incomplete on purpose because execution on a blockchain is transaction-based and computation is expensive. Iterative computing can lead to unsafe states and hidden bugs that cannot be checked, so the team feels that is best left out of the scope of blockchain programming. Even languages that are Turing complete on blockchain are limited by gas, which then makes it not complete. Safety is greatly enhanced by this design choice limiting scope
Formal Verification - complete FV system for all user code. When users write Pact, they annotate the expected restrictions in the code, and after saving locally, the file is run through a solver. If the restrictions do not pass, the user is notified with error messages
Access Control with Capabilities - capabilities permissioning for granular access control: granted via time, sets/groups, “once-and-only-once” vs multiple time access. Can also disallow actions
Using These Benefits -> A Cool Idea: Community Gas Stations – potential users often don’t sign up because of the difficulty in set up, from creating wallet to backing up keys to purchasing tokens. Pact would allow a dapp developer to pay for the gas instead of the user. It would also allow developers to request gas reimbursements from Kadena. It might also eventually create a market for co-signers, who take care of paying for gas for the ultimate user and requesting reimbursement from Kadena, allowing dapp developers to not have to worry about this and not have to store a large number of coins

Hybrid Layer 2 Protocols – Vitalik Buterin, Ethereum

Tuesday, October 29th, 2019 | 2:50pm

Vitalik gave an information-packed talk on Rollups, a concept he first wrote about and set aside years ago, only to return to now. Below are all his slides - minus 1 missed due to the speed of his talk.

Existing Layer 2 Protocols - data and computation are done off chain (except for deposits, exits, and disputes) since computation can take a long time
In A Standard Interactive Challenge Response Game - Submitter submits transaction with a deposit, there is a challenge period where anyone can submit a challenge at a point (challenge index i). If submitter is wrong, submitter loses deposit and challenger gets part of it as a reward. If there are no successful challenges during the challenge period, the result is accepted. This is very friendly to challengers and honest players. Not friendly to bad submitters.
Partial data - if some data is missing, you won’t be able to prove 100% of things. Can we use a similar idea to make sure all of it is available? Actually no, data doesn’t work like that
To illustrate the above point, see the slide “Data Availability” with 2 cases. In these two worlds, in case 1, the submitter left out data and was successfully challenged so submitter then publishes the missing data. In case 2, the submitter was honest and was erroneously challenged. If you download data after time T3, both sides look the same. You have no idea if the bad guy is the block proposer or the guy sounding the alarm. So therefore the reward to T2 must be the same. If the reward is <= 0, nobody would bother challenging. If the reward is above 0, you incentivize false alarms
Plasma and channels don’t try to create global consensus on whether all data is available – it instead pushes responsibility to the user. If you decide your counterparty is withholding data, you just switch to someone else (don’t have to prove anything to anyone, you just switch)
ZK Rollup – have smart contract and that contract stores Merkle root of state. Users send transactions but they don’t send to the blockchain directly, and send instead to a 3rd party called a sequencer or aggregator. The sequencer smushes together the transactions and creates a zero knowledge proof. 1 single zk-SNARK verifies that all of the transactions are valid and you can prove the beginning state hash and end hash are correct. You only use about 12 bytes of data for each “roll” of transactions, since you can throw things like individual signatures away
Computation is done by the sequencer and people who want a full copy of the chain (maybe to become a sequencer in future), not the blockchain. Storage is also off chain. A small amount of data is on chain, however data is cheap and is going from 68 to 16 gas cost
Optimistic rollup – similar to zk but no zk proof. You submit with a deposit and there’s a challenge period. Storage and computation are still off chain. Enforcement mechanism is an interactive challenge response game instead of zk-SNARK
ZK ZK rollup – inside is private
Ethereum gas limit is now 10 million! So the numbers on the Statistics slide go even higher
The main bottleneck is SNARK proving. It’s very possible that the next form of mining is zk-SNARK proving (though it’s not as lucrative as current mining)
Shards and rollups can play together, and could be a good path to scaling apps on Ethereum. It might make sense for rollups to charge for storage rent
Hybrid layer 2 solutions do have the ability to collect transaction fees -> could use that to fund interesting things
Questions from the audience included asking if he foresees the system rolling up to 1 single roll up chain? Yes, that could be a good way to go
How would sharding and rollups work together? It’s an optimistic system – if shard talking to shard is slow but shard talking to client is fast, client can calculate immediately what the output should be, and it can create a very fast cross shard experience
What’s the most interesting chain structure? Chain structure internally doesn’t matter, it’s a matter of what it provides. However he likes quadratic chains.