Will you provide an incentivized testnet?
Applications for our incentivized testnet are now open, you can apply here. The application deadline is March 20th, 2021.
When are the Agoric mainnet and token sale?
Our current plan is to release mainnet in the summer of 2021. The timing for token sale has not been determined.
What is Agoric trying to achieve?
Agoric believes that bringing the world economy online requires making it easy for the world’s programmers to develop smart contracts. A key to this is enabling a safe and secure development environment which Agoric is able to achieve through our object-capability-based Javascript execution environment, building on the team’s decades of prior research and successful implementations carrying billions of dollars.
We have released a proof-of-concept of our object capability-style JavaScript execution environment, The Agoric “SwingSet” Vat Library.
What are object capabilities?
In programming, we often want to restrict access and only give certain users or programs the authority to perform certain tasks. Object capabilities (ocaps) and access control lists (ACLs) are two ways of handling access control.
Identity-based access control such as ACLs make sense at the boundary of humans to computers, such as when a new employee is hired and given a certain set of permissions which will rarely change. However, in order to bring the world economy online through smart contracts, we need the ability to rapidly derive, compose, and transfer rights among a mix of computer agents and humans. ACLs have difficulty handling this level of complexity.
We often use the example of valet parking to distinguish between ACLs and object capabilities:
Imagine you are checking into a hotel and drive up to the valet parking. You hand them your key, and continue checking in. Later that night, you want the car to go out for dinner. The original valet has gone off duty, but there’s no trouble, since he has given the key to the new valet. In this example, the key represents an object-capability.
But what if your car used an ACL instead? You check into the hotel, but this time, you take down the name of the valet and add it to your car’s list of people who are allowed to drive it. However, when the new valet goes on duty, the old valet doesn’t have the permissions to edit the car’s access control list, so the new valet cannot retrieve the car.
Perhaps, anticipating this, you hand over your driver’s license to the valet when you check in. Then when the new valet comes on duty, the old valet can just transfer over the driver’s license, so that problem is solved. However, now the new valet can take your ID and steal your identity. Letting the valets act as you enables them to do anything you’re allowed to do.
In an ocap framework, rights are represented by computational objects. Holding the object (having a reference to it) is fully sufficient for being able to use it. Therefore, access can easily be limited to the least authority necessary.
Current smart contract platforms generally use identity-based access control, which has known limitations. Smart contract developers have found ways to work around the limitations of identity-based access control, but ultimately, these limitations are insurmountable when trying to create a fluid world economy. For instance, it is currently possible to write a simple smart contract to give someone the power to buy an asset (say, a stock) at a certain price over the next month. This is effectively a covered call option. However, the covered call option in Ethereum or another smart contract platform can’t participate in the larger market — the person who has access can’t turn around and sell the access to a third-party. The contract creator can write a transfer function, but then the contract creator must be able to anticipate all of the needs at contract creation and writing smart contract functions is expensive and error-prone. By contrast, with ocaps, transferring the right to a contract is trivial, and access to an opportunity becomes a bearer instrument by default, allowing something like a covered call option position to participate fully with the rest of the ecosystem, such as being sold at auction, on exchanges, etc.
Why JavaScript?
JavaScript may seem like an odd choice for programming secure smart contracts. JavaScript is a complex, dynamic language providing great flexibility and expressivity, but occasionally at the cost of errors, vulnerabilities, and hard to understand code.
Despite these flaws, JavaScript is used by millions of developers, making it the most widely used programming language in the world. But popularity isn’t the only reason to use JavaScript. JavaScript actually has a number of features that make it ideal for smart contracts, and the Agoric team (in particular, Mark Miller) has been working through the JavaScript standards committee (TC-39) to improve it further.
Due to an accident of history, JavaScript is a language with a clear separation between internal computation and access to the external world, such as users, timers, networks, and files. This separation is an almost perfect analogy to the hardware distinction between “user-mode” and “system-mode” instructions. Because of this separation, we can intercept access to the external world [1], confining a purely computational subset of JavaScript.
Because of JavaScript’s unique separation of computation and external effects [2], most host independent JavaScript programs that engage in generally recognized best practices (such as using strict mode) run perfectly well with no other alterations in our secure subset of JavaScript, called SES. SES builds on a number of changes that the Agoric team has championed through the JavaScript standardization process, including strict mode, proxies, weak maps, tagged template literals, and promises, which were derived very directly from the promises in Mark Miller’s E language, and were designed both to support distributed computation as well as manage local asynchrony.
Because of JavaScript’s widespread use, the language has been highly tested. Unlike a new Domain Specific Language (DSL) for smart contracts that may have only been used by a few people, the pitfalls and peculiarities of JavaScript are well-known and can be avoided, rather than discovered too late.
For more on Agoric’s secure subsets of JavaScript, please see the Jessie repository.
[1] A JavaScript program can only obtain the ability to create external effects by dereferencing global variables, such as window or document in the browser, or fs (the file system) in Node.js. These scope lookups can be intercepted, analogous to how hardware provides an operating system designer the ability to intercept access to the hardware and external world.
[2] There are four exceptions to the clear separation between pure computation and effects: Date.now(), Math.random(), timezones, and current locale for purposes of internationalization. SES repairs these by other means.