What Is a Smart Contract?
Smart contracts pre-date blockchain by several decades, though they’ve come to be synonymous with blockchain and Web3 technologies. As Dean Tribble of Agoric put it in an interview with The New Stack, “at the core, a smart contract is software that is enforcing the terms of an arrangement, like a legal contract made between third parties.”
Some familiar examples might be something like Uber using software to connect you to an unknown driver who agrees to take you to a pre-selected destination; this is a kind of smart contract. The transaction requires a trusted intermediary, in this case, a centralized software company, that has privileged access to information like your credit card and location on the payment side, and driver availability. The software connects both sides, giving you a ride and the driver a fee.
“Blockchains bring replicated execution,” said Tribble, “where you have machines in multiple jurisdictions and administrative domains all voting to agree on what happens. That consensus across jurisdictions means that no organization or government can compromise the integrity of execution.”
This allows for things like financial transactions that span borders in a more complicated trust than a driver and rider located in the same town. Agoric’s goal is to enable much of the world of commerce to work in that environment, which means it needs to be programmable by more than a few thousand developers. So it doesn’t get better than a language that 16 million developers understand, allowing them to use a familiar development environment.
I asked Tribble about potential downsides, and he started with a pithy response, saying, “There are probably downsides, but it doesn’t matter. Github did an analysis and 97% of the code in [applications on Github] is from third-party libraries.”
But he followed up with a little more detail.
“There is a lot of disadvantage to specific component models,” he said. “You really want a language, framework, and libraries that minimize security hazards while making it easy to put together. React is a good example of this because the model had the affordances and solved the right challenges for plugging things together. There were lots of user experience frameworks before React, but React got it right. Our components are like React components and our framework supports using our components and composing an application with other components.”
What About Security?
The Solidity programming model, by contrast, has security hazards and issues with things like reentrancy. Reentrancy has been an issue with synchronous programming models for as long as there have been synchronous programs. This happens when a program can effectively repeat the same request to another program multiple times before the requestor gets an acknowledgment that the initial request was completed. This means, for example, that you can ask for the same amount of ETH repeatedly and keep getting more ETH before the program you are requesting it from has time to acknowledge that you got your money. Will Shahda offers a good example of this on Medium.
According to Tribble, the risk of these reentrancy attacks was pointed out by Agoric lead engineer Brian Warner in a security review of Ethereum before it went live. He also acknowledged that it was potentially the right tradeoff to make at the time. Moving to an asynchronous model allows you to avoid a reentrancy problem, but due to this being a fundamental feature in Ethereum’s design, it isn’t something that can be addressed.
Reducing Fees for Usage
One of the biggest complaints about Ethereum is the gas fees associated with proof-of-work. At the core of this problem is a fundamental misalignment between people who want to increase activity on the Ethereum network and the miners who want to increase fees. As Tribble puts it, “the miners are the slum lords and Ethereum is the tenement. The only way the landlord gets more money is to raise the rent.”
In addition to being a Layer 1 proof-of-stake network, Agoric is looking at addressing this economic incompatibility in order to align the priorities of their blockchain network with the dynamics of a functioning economy. As a result, they separated their governance token, BLD, and their fee token, RUN — with the intent of RUN being a stable token that doesn’t fluctuate.
Tribble explains the reasoning this way: “Think of gas fees as your rent or electric bill. Ethereum is like paying for your rent with shares of Apple stock. It’s not great from a business planning point of view. It’s difficult to compare if rent went up or down from month-to-month. What you want instead is to be paying in a stable token for gas, which means it needs to be intrinsic to the chain and it shouldn’t be going into the pocket of validators — so there isn’t an incentive to raise the rent.”
This is where RUN comes in. “RUN that is used in execution goes into currency reserves to provide stability and execution growth for the chain,” Tribble said. “All the fees for the validators come from fees for borrowing RUN, not paying for execution. That means, as the economy grows, as I send you more checks, as I buy more NFTs, as I lock up more tokens, the amount of RUN in circulation goes up and a small fraction goes to the BLD holders for staking and delegation. So their reward grows as the economy grows.”