Clearmatics at SBC19

In the last week of January, I attended the Stanford Blockchain Conference in Palo Alto, which was a great experience.

Giuseppe Giffone
clearmatics
8 min readFeb 22, 2019

--

The aim of this post is to debrief my days at the conference and share with you what I found most interesting and inspiring. Hope you enjoy it!

Photo by Ian Mackey on Unsplash

We made it!

Stanford Blockchain Conference was in its third edition, previously known as Blockchain Protocol Analysis and Security Engineering(BPASE), with the name changed for clear reasons. We couldn’t miss the chance to attend it, so after 3 years, we made it!

“Last year we had four hundred attendees, this year two thousand, so if you extrapolate, it’s pretty clear next year we’re going to have ten thousand. So, the conference will take place at Stanford’s Football Stadium.” — Dan Boneh

The increasing numbers of participants is a proof that it has begun to be a landmark in the blockchain space, where the more interesting research projects are presented. This year, the Program Committee was lead by Dan Boneh, Professor of Computer Science and Electrical Engineering at Stanford, and one of the Program Chairs was Byron Gibson, consultant and advisor of Clearmatics.

Stanford University is very active in blockchain research through The Stanford Center for Blockchain Research, where cutting-edge research is conducted, and seminars and events like these are regularly arranged. This strong commitment from the academics is a further example that blockchain will be at the foundation of our technological future.

Selected talks

These are part of selected talks I found really interesting and that I briefly summarize below with some additional references.

WARNING: High Content of Cryptography

The majority of my favourite talks directly involve cryptography or its derivative.

Building, and building on, Bulletproofs by Henry de Valence and Cathie Yun

Henry de Valence and Cathie Yun work for Interstellar and at this year’s conference they discussed part of their previous work as well as some of their ongoing work around Bulletproofs implementation. They were also at BPASE in 2018, where they talked about a new design for blockchain virtual machines.

Their talk was split in two parts, with the first describing the work underlying their Bulletproof implementation, and in the second part, they discussed what they constructed on top of Bulletproofs.

In the first part, they introduced Ristretto, a project that tries to solve the problem related to prime order group implementations. For example, the use of Edwards curves implies dealing with a small cofactor: this means that security proofs of the abstract protocol don’t apply to its implementation, extra validation is required, etc. There are some ad-hoc tweaks that work (not an easy task by the way) but these can generate side-effects on the protocol. For example, in Monero, insufficient validations on the signatures allowed to spend the same amount 8 times.

The Ristretto project, based on Decaf, is a variant that works with cofactor-8 curves like Curve25519. It’s worth highlighting that in their ristretto255 group they achieve 4x faster signature verification in comparison to secp256k1.

In the second part, Cathie Yun showed how they extended their implementation of bulletproofs (more info here): it’s worth mentioning these are an API for multiplicative and linear constraints as well as a confidential assets protocol called CLOAK and ZkVM, a Zero-knowledge virtual machine (ongoing work).

Slides

https://cyber.stanford.edu/sites/g/files/sbiybj9936/f/bulletproofs_sbc19.pdf

Further references

Accumulators for blockchains by Benedikt Bünz

Benedikt Bünz is a PhD student at Stanford. He is part of the Applied Crypto Group and was member of the Program Committee, with Dan Boneh and he talked about his recent work: Batching techniques for Accumulators with applications to stateless Blockchains and Interactive Oracle Proofs (IOP).

In UTXO models, it turns out that state size (number of unspent transactions) continuously increases. Moreover, to validate a transaction each miner needs to have the entire state, so it would be beneficial to move towards a stateless consensus where the state is substituted by a commitment on it. In this kind of systems, a user needs to also provide a “proof” against the state commitment. This means that part of the burden is moved from the miners and validators to the users. More concretely, in Bitcoin we would have an accumulator h = Commit(S), where S is the set of unspent transactions, and, in order to spend some of these, a proof is required to indicate that they appear in the commitment (so they are unspent). In general, accumulators need to have the following basic functionalities: add/remove unspent transactions, prove/verify membership proofs. Some examples the presenters gave for this were Merklee Trees, RSA Accumulators and Pairing-based Accumulators.

Merklee Tree used as accumulators have a communication downside, because we have one witness per UTXO, thus creating a bottleneck for the system. An ideal solution should have: short membership witness per item, efficient accumulator updates (in terms of storage and computation) as well as efficient verification. Therefore, it would be great to have the possibility to aggregate proofs between multiple users in order to have batch generation & verification. State of the art RSA Accumulators have good properties and Benedikt showed how to update them and generate/verify membership proofs. An important downside, however, is that they require a trusted setup on two primes p,q, whose product gives the order of the group the accumulators are constructed upon.

In their work, they managed to achieve more properties such as aggregate/batch inclusion proofs(many at the cost of one), while also being trapdoor free. Some of the ideas behind these developments are the use of groups of unknown order and arithmetic tricks. To close his talk, he discussed account-based systems (e.g. Ethereum) where vector commitments are needed (more details about these can be found here and here). They described new vector commitments with batching functionalities and reduced number of parameters (e.g. in current works to commit 1 million vectors, you need 1 million parameters). This improvement comes at the cost of more work for the Prover. He also mentioned how their vector commitments can enhance some aspects of IOPs constructions like STARKs or Aurora.

The takeaway point from the talk was about the feasibility to shift part of the burden from miners to users, storing the part of the state they care about or alternatively, outsourcing this task.

Paper and references:

ZEXE: Enabling Decentralized Private Computation by Pratyush Mishra

Pratyush Mishra is a second year Computer Science PhD student at UC Berkeley, supervised by Prof. Alessandro Chiesa, co-author of the Zerocash paper. He talked about ZEXE, his work about private computation on decentralized ledgers.

Today, computation on distributed ledger technology implies re-executing the computation and data leakage, which has effects on scalability and privacy. ZEXE is a ledger-based system that enables users to conduct offline computations and then publish transactions about these. From a privacy perspective, no information is leaked about the offline computation and transaction validations happen in polynomial time. It has great functionality since this applies to user-defined functions. In addition to these theoretical results, their paper showed how to construct examples of applications such as private user-defined assets, private stablecoins, and private decentralized exchanges.

In the talk, Mishra focused only on how to use ZEXE ideas to construct private user-defined assets and private decentralized exchanges. They extended the Zerocash paradigm in order to construct private user-defined multi-assets. The idea was to modify the coin by adding a variable representing the type of asset: this allows one chain for every different assets without splitting the anonymiset. In order to have atomic swaps between different assets, they added some extra data and a death predicate (it can be thought of as a bitcoin script). More details can be found in the video included above or the paper below.

In terms of private DEX’s, he introduced the typical required functionalities as order creation, order discovery and trade finalisation, explaining that they depend on the architecture of the exchange. Their paper focused on two types:

  • order-based, where an order book maintains list of orders published by makers.
  • index-based, where an index maintains list of “intents-to-trade” published by the makers.

In the talk, Mishra analyzed the index-based one. The idea (again) was to add into the coin some extra data and a predicate related to the assets they wanted to trade. Moreover, he showed how ZEXE can manage more complicated policies (e.g. stablecoin enforcing white/black lists on the supported transactions, ERC-20 token requiring value-conservation) by adding a birth predicate when the coins are mined.

Paper

Worth to be mentioned/viewed

Here are other talks I really enjoyed and strongly suggest watching the presentation and reading the papers I’ve included below:

Final thoughts and acknowledgements

It may seem redundant but I want to underline the importance for everyone working in this area to attend these kinds of events. I think that the disruptive potential of blockchain technology comes at the cost of its constantly evolving nature. There is an incredible amount of ongoing work and the amount of ideas floating around (especially at the research stage) make it fundamental to connect and interact with fellow community members. So let’s share our ideas and get inspired by these to create new ones.

Finally, thank you to Clearmatics for giving me the opportunity to attend the Stanford Blockchain Conference as well as to the speakers for their contributions to the community and to all the individuals involved in organising the conference.

Hoping to be there next year again, maybe presenting part of our work!

Cheers,

Giuseppe

Giuseppe Giffone, Protocol Engineer, Clearmatics

Tweet us @Clearmatics

--

--