The Metaverse Podcast - Rapid DeFi, with Dean Tribble of Agoric
Primer: What’s more important than transaction speed, volume, and latency? The programmability and the programmer base. In this episode of the Metaverse Podcast, host Jamie Burke speaks with Dean Tribble of Agoric on his project and why having more programmers being able to code in your language is important.
Background
Worked at Xerox PARC many years ago
Worked on the first production smart contract in 1989
Was one of the early cypherpunks
Before Agoric, he was working on a multi-billion dollar payment instrument in the US
Before that, he was working on secure operating system research at Microsoft
History Of Agoric
A Proof-of-Stake chain with composable JavaScript smart contracts
Dean and Mark S. Miller, the Chief Scientist, have been working on Agoric for 3 decades
Dean worked on the first production smart contract back in 1989 when Mark did his open Agoric open systems papers back then
Agoric (the company) was founded in December 2017
Zooko from Zcash, a friend of theirs, knew that they had a deep background in smart contracts and security. Organized a group and invited them in
The Innovation They Bring To The System
Most important innovation — programming smart contracts using hardened JavaScript
Scaling is difficult and comes in many different forms
The hardest and most important form of scaling is to scale the number of programmers in the world who can program the blockchain
“And that's why our focus is on how do we have something that's programmable by millions of developers, not thousands of developers, and that's programmable rapidly, where they can put together stuff quickly, and have the result have a high chance of being safe.”
- Dean Tribble
They have worked with the JavaScript Standards Committee to drive hardened JavaScript into JavaScript
Have worked with Salesforce, Bloomberg, and NodeJS in developing that core technology
Also working with CosmJS, Keplr, and MetaMask
Why Is JavaScript Safer Than Other Languages?
As an accident in history, JavaScript was standardized in the ECMA Standards Committee, the web bindings for it in W3C, and the node bindings in the node foundation, etc.
Committees defend their territory by using user mode-system mode separation
User mode: part of your OS where applications are run
System mode: The kernel has all the power
The boundaries between those 2 modes is the core of how you make program interaction safe on a platform
Because of the accident in history, the user mode-system mode separation in JavaScript is stronger than in any other languages
People have the perception that JavaScript is insecure because things are very changeable
However, the hardened JavaScript that Mark S. Miller drove into JavaScript made it very well-specified and secure
“And that means that we really can have an environment that we download and run arbitrary JavaScript code in a box, and it really can't get out and, and touch, talk to, or steal secrets from other parts of the system. So we get real encapsulated execution.”
- Dean Tribble
JavaScript is highly composable — developers could use components from other developer’s frameworks instead of writing it from scratch
“And the net result is a beginner with several months of training can do better than an expert used to be able to do because you have these frameworks that are really well designed.”
- Dean Tribble
On Composability
In 2018, people did not understand composability
People discovered that Ethereum transactions could involve multiple interactions with different smart contracts in a single transaction
For example, Uniswap plugged the Compound governance elements into their system and it was a success
dForce did the same thing, but lacked the background knowledge and suffered an exploit as a result
Composability means that it’s easy to copy other people’s code but it is not very maintainable or extensible
Design Principles, Lack Of Scaling, And Ethereum
Important to note that things have scaling limitations and that starting with small applications is fine as well
At the beginning, HTTP was terrible. It had no security, pipelining, etc.
However, this was necessary to get the world kickstarted. It led to the development of HTTPS, HTML5, JavaScript, etc.
Does not want to second guess the design decisions in Ethereum
Differences In Approach Between Solana And Agoric
Thinks that the hardest scaling is programmability
Solana and other L2 solutions are scaling transaction rates, volume, latency, etc.
Solana is building a high frequency trading engine
Agoric’s focus is on scaling programmability and the programmer base
Each project has its own focus and target market
Key Primitives That They Have Been Building
In 2015, Mark Miller wrote a paper for financial cryptography in a JavaScript-like language
The paper resulted in the electronic rights transfer protocol, which is an API rendered in JavaScript that enables the trading and exchange of fungible and non-fungible digital assets
Agoric has been built around the trading/exchange of digital assets
Users will be able to bridge a token from another chain to Agoric
The growth of JavaScript frameworks ramps up programmability and the reusability of components
As A Cypherpunk, Where Does This All Fit In?
As a cypherpunk, he wants to enable people to permissionlessly implement and deploy some new way of cooperating with people they want to cooperate with
The elements to make it easier and safer is through these reusable components
Cypherpunk Culture And US Regulation Around DeFi
Wants stuff to be as permissionless as possible
Agoric (the company and the employees) is working very hard to be as compliant and as transparent as possible with regulators
What’s Coming Up On Their Roadmap?
Just finished their incentivized testnet. Have received lots of feedback on it
Will be rolling out their phased Mainnet in Q4 2021
Join their Discord
All information presented above is for educational purposes only and should not be taken as investment advice. Summaries are prepared by The Reading Ape. While reasonable efforts are made to provide accurate content, any errors in interpreting and summarizing the source material are ours alone. We disclaim any liability associated with the use of our content.