Is JavaScript the Future of Smart Contracts? – InApps Technology 2022

As we highlighted in our article The Web3 Stack, a considerable portion of frontend development in Web3 is being done with a technology very familiar to Web 2.0 developers: JavaScript. This means there is plenty of opportunity for the estimated 16 million JavaScript developers worldwide to participate in building the next phase of the web. Now Agoric, a Layer 1 proof-of-stack blockchain, is making a big bet that JavaScript can also be used for smart contracts, which are fundamental to the decentralized trust that is core to Web3 decentralized application development. Up till now, smart contracts have primarily been programmed using languages like Solidity or Rust.

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 InApps Technology, “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.

Right now, programming blockchain smart contracts is limited to the relatively small number of people who know how to program with Solidity, the smart contract language for Ethereum and its Layer 2 sidechains, or other languages like Rust on Solana. Agoric is helping JavaScript developers fast-track past the hurdles to implementing smart contracts, the same way that React made it easier to build JavaScript applications using reusable components.

Downsides to Using JavaScript for Smart Contracts

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?

Agoric is using hardened JavaScript in their component model for building composable smart contracts, which limits what a JavaScript runtime can do.

“Hardened JavaScript allows you to lock down your JavaScript so that it’s impossible to do things you don’t want it to do,” Tribble explained. “The authority that comes into a program is entirely controlled by the scope in which that program runs. We control the scope. You run with exactly the access and authority we provide, so [that] we get real confined execution of arbitrary JavaScript.”

Agoric has a detailed exploration of hardened JavaScript, which included this example image:

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.”

JavaScript as the Future of Smart Contracts

It remains to be seen whether Agoric will succeed in generating massive adoption for its composable JavaScript smart contract components, but React certainly seems like a successful model for building a component-based framework. Layering in a predictable cost control structure will also play a role in helping decentralized applications understand the cost of doing business. Agoric is also planning for interoperability, by making it possible to connect with Ethereum and Cosmos by way of the Inter-Blockchain Communication protocol and the Chainlink oracle network.

What does seem to make a great deal of sense is allowing JavaScript developers who already have deep experience, in the financial sector in particular, to leverage that knowledge along with their background in meeting financial compliance guidelines and security standards. That particular segment of developers also tends to have strong experience implementing applications for hundreds of thousands of users with varying degrees of tech-savvy, so coupling their UX knowledge with an easy way to compose smart contracts might be a winning combination.

Featured image from DepositPhotos by peshkova.