## Points: I also want this to tie together my three approximate threads: 1. Hackable Solidity/WASM/EVM execution engine (I don't want to make this the main thrust) 2. Burrow in the multi-chain world: side-chain/burrow-in-a-box/public permissioned/personal node (c.f. Studio) 3. Burrow - Build your own Cosmos Zone Outline Intro: 3 minute Point 1: 7 minutes Point 2: 7 minutes Point 3: 7 minutes Conclusion: 4 minutes Plea: 2 minutes (signpost other talks) Questions: remaining time Total: 30 minutes (40 minutes) allocated With speakers notes this document probably needs to be 3500-4000 words for 100 words/minute.

Hello I my name is Silas, I am the longest-standing maintainer of Hyperledger Burrow, the CTO of Monax, and an erstwhile Hyperledger Technical Steering Committee member. ### Interests - Dancing - Cheap wine - Blockchains

*I will describe Burrow and attempt to convince you that:*

- Embeddable, what we are most known, for but not the first thing we think of when we think of burrow - Sidechain: about how Burrow relates to, and is companion to 'state elsewhere' - Cosmos: How Burrow is exceptionally well placed to be Hyperledger's gateway to the Cosmos ecosystem *By considering the three characters of Burrow:*

A few different ways into that: - The oldest Hyperledger codebase of which nobody has heard. - Burrow and Tendermint have eris-db as a common ancestor - they used to be a single codebase - Tendermint a PBFT-style with a novel linear view-change - Tooling: that tooling is mostly lovely

- They are all problematic - Even more boring than Git is stupid. - The kind of boring that lets you sleep well at night.

- Predictable: - pure go binary performance which is easily profiled - consensus mechanism with no leader election - fully deterministic execution - complete rollback-version history and built-in forensics tooling when things go wrong - No killer feature: - We don't have fully-homomorphic steganographic meta-consensus, but we do have nice logs - No single gimmick - No great novelty in the individual pieces we have - But the combination and orchestration is - An EVM with permissions - Go native functions that can be called from WASM and EVM - Fine-grained event stream stored in an immutable trie - Ed25519 and secp256k1 support

- Simple is a cursed description - rarely does software set out to be 'complex and slow' - so simple can be weasel-word - Easy to understand: well-structured commented code, discoverable - Easy to operate: logging, metrics, and kubernetes support - Needed features: if a feature is needed in wild to make useful, we take an opinion, and include it - Burrow likes to borrow: And we shirk responsibility for those features... 'get someone else to do it'

- fast enough, i.e. fairly slow -D - lots of room for improvement and we will - we are not the scaling bottleneck - Vent helps the scaling target (c.f. Vent / RDMS) - BFT/Tendermint favours just exploding rather than getting it wrong. - Rollback mechanism if anything is corrupted

My hackneyed phrase aiming to encapsulate these ideas and bask in the reflected glory of redic

- Casey, Preston, and Tyler and decentralised video sharing use-case for a competition - Tendermint and Burrow shared growing pains and both stronger because of it. integration runs deep

- We appear to have small cannabis market following - Legal tech and cannabis - Pleasing combo - Please come and talk to me if you use Burrow

These ideas are looking to the future, but we have significant support in these directions already - The Hyperledger community could benefit by exploiting the public chain ecosystem - To track and prove state across different chains - There should be more interest than there is - Cosmos: internet of blockchains, see part 3 - Most of 'blockchain' is in git already - burrow can operate in a mode like a git repo - join a network and synchronise - core use-case, legal agreements, the abiility to use the same structures in different contextx - privately transact privately amongst counterparties is compelling. - A hop skip and jump away from flexible ad-hoc state channels - just `burrow init`

Point 1

- Using interfaces is not something of which to be excessively proud, - Much pain over there years has wrought solid engineering boundaries - Our split from Tendermint and our love of Borrowing/reuse, as well as being a good dependency for other projects means we care about thsi

You can extend what we have in interesting ways - Kernel: export our functions (unlike go-eth that is not trying to be embedded - You could run us in other context - e.g. DB backend - We use our own embeddability to provide no-consensus mode

- This is an admittedly crude way to compare - but code is our biggest liability so I am going to do anyway

- Note does not include dependencies for either project - Not an apples to apples comparison etc - BUT STILL...

It's boring, but no containers needed - Specify and configure a chain from the comfort of your commandline - multi-chain support - debug, introspect

- GRPC: use from any language - robust transport layer - Protobuf: high level abstract interface and commitments as well as efficient binary protocol - Names: Burrows DNS - Execution events: powers may features and ways of thinking about things incuding vent

- Vent with burrow.js, vent helper, synchronisation, single system illusion - This gives you query-side scaling - Ability to run traditional databse and blockchain togethe

The chief motivator for this functionality is given we that our state must have bit-perfect alignment. How do we move fast and break things? Our pragmatic answer is to implement `git rebase` for blockchains. Sacrilege!? Kind of... We actually form a chain-of-chains via an AppHash (state root hash) in the genesis of the new chain poiting to the old chain at the fork height - Upgrades: e.g. improve binary format, improve storage space, fix bugs - Backups: a quickly addressable backup in a manipulatable protobuf/JSON format - also useful for data mining and import purposes - Forks: perhaps some participants of a network would like to run a fork not including some transaction this provides a mechanism for starting a new instance with the state at some height - We also have plans to allow forks to be orchestrated via our on-chain governance primitives (see later!) - Redaction: Sometimes the law requires we remove some information - perhaps our blockchain/other system data split needs to change. This gives us a mechanism

Point 2

- Elsewhere: database, other chain, blob store - Prove: data may not be stored but proof of interactions (e.g. acceptance, approval, consent, signature) in database, mainnet, etc may be - Extrinsic: a bond that can be slashed, need to cooperate, etc

Scale invariance: a common runtime between these allows you to track and prove state across other systems - Agreements and process repository, put it on a thumb drive - Cloud: etcd alternative, BFT? why not? - File-based backend c.f. SQLlite - Staking e.g. delegated proof of stake, random elections

- This comes from our experience with legal agreements, we have our core interaction on chain - Shared data: model data users share as if it is public there are benefits: - Strong audit log - Less noise (billings, organisations, profile information) - Ready for public-network spin out

- Bonding - the ability to vote and become a validator - possible to only - Proposals allow accounts with the PROPOSAL permission to propose an alteration to the network. - GovTx is a transaction type that is often behind a proposal-wall with the ability to arbitrarily update an on-chain account. This is a 'Root' permission - you can grant it to no-one, or online let a smart contract have it. Flexibility for all kinds of networks - both moderated and permissionless - Burrow nodes need to have the BOND permission to act as a validator - A variety of bonded proof-of-stake and proof-of-authority networks can be built using this model. - We will be providing additional crypto-economic primitives

Very useful feature not found on other ethereum clients to my knowledge - Contract metadata can be found - What is deployed at this address?

Delgate: can sign on someone's behalf user proxy contract

Point 3

- IP routing analogy, escalate a transaction to hub-chain (really 'next chain up') when you need to get it somwehre - Track validator state, and provide light proof thing you care about happened somwhere. - See also: polkadot - Digression: EOS, VRF validator functions, Async (e.g. hashgraph)

- Support: IBC work + long-standing support of secp256k1/ed25519 for eth side-chaing - Ready: side-chain has been driving burrow development for a long time - Agreements Network and our tendermint history - A proven dapp framework to run on cosmos - SDK is interesting but more focussed on apps within zones and possibly overengineered for som euse cases

Thanks to one of our maintainers Greg Hill we have some early work on implementing some of this protocol

- Burrow packs a large number of features in a modest package - Burrow is boring (in a good way) - Utilitarian: we include features where there was a need, where you will need it in real life - Our features are wrenched painfully from compromise - Ambilavent: - public/private/cloud - ethereum/cosmos or other source of truth - synchronised full network or local repository - Proof-of-stake, proof-of-authority, benevolent dictator

- Can: documentation, EVM fixes, tooling, testing - Should: you might be sweating needlessly trying to _configure_ something else to do your will. - Just hack Burrow - Will: if that doesn't work, then maybe a threat will...

Wednesday, March 4 • 3:00pm - 3:15pm