Scrypto v0.4 is here, bringing with it our first public test environment for Babylon, a primitive sneak peek of how a website can interact with an on-ledger application, and a shiny new authorization model.  There’s a lot to cover, so let’s jump right in.

Enabling web frontends

Ever since the release of Alexandria, the most commonly asked question by devs has been “How can I connect a website to my Scrypto component?”  With the release of v0.4, we finally have an answer.  It’s rather coarse, employing placeholder versions of tools and libraries which will be greatly improved in the future, but it works!

The system looks something like this:

• We host a public test environment which runs a copy of the Radix engine simulator and a filesystem-based ledger.  It’s not a network, and there’s no consensus process running.
• The public test environment exposes a REST API which allows developers to publish code, submit transactions, and perform read requests about ledger state.
• We offer a Chrome browser extension which behaves like the most basic imaginable wallet.  It can sign transactions and submit them to the test environment.
• We offer a JavaScript SDK which can assemble transactions and knows how to talk to the browser extension and the REST API.
• Website developers can import the JavaScript SDK and use it to establish a connection to the browser extension as well as the public test environment.  They can query for information like account balances, build up a transaction from user intent, pass that transaction to the browser extension for signature and submission, and then receive back a result of what happened.

‍

The end-user experience is a far cry from what you can expect later this year, but it gives devs the ability to experiment with building out a critical piece of their dApp - the user interface.  It’s also the first opportunity to compose transactions involving components written and deployed by multiple different people to a shared environment.

With this release, it’s finally possible for devs to come together to build and test the first “mini DeFi ecosystem” on Radix.  Who will be the first?

Solving authorization the right way

Safe, powerful, and easy-to-use authorization is foundational to the success of DeFi, Radix, and Scrypto, and we knew that we needed a greatly improved model from what we initially released in December.

Our biggest design challenge was creating a system that “gets out of the way” so you barely have to think about it 95% of the time, while still allowing complete flexibility for unusual scenarios that require highly complex rulesets.

After months of thinking, tinkering, and listening to feedback from our developer community, we have finally cracked the problem and are releasing the new model.  We can’t wait to see what the creative minds of our community will do with it.

Introducing unified system-level authorization

There are two primary use cases which require robust access control: guarding access to a component method call (e.g., only the owner of this account should be able to withdraw tokens from it), and restricting who is able to manipulate resources in various ways (e.g., minting, burning, changing metadata).  In Scrypto v0.4, the system inherently understands both of these needs, and can “just take care of it” without the user or developer having to be explicit about authorizing these actions each time.

How does it work?  For a particular action (whether method call, or resource action), a developer can set the rules that govern when it is permitted. For example, you might want to specify that “2 of these 3 badges must be present in order to mint more of this token.”  When creating a transaction, required badges can be fetched from wherever they are located (maybe one is in a user’s account, and another is held in some other shared component which in turn needs a different badge to retrieve it), and they are automatically placed in something we call the authorization zone of the transaction worktop.

During a component call from a transaction, the system is always aware of the contents of the authorization zone.  If a called component wants to mint more of a token, it doesn’t have to explicitly specify any badges to do so; it can just attempt the mint action, and the system will determine if the minting rules can be satisfied by the collection of badges present in the authorization zone.

This exact same kind of logic, and same method of specifying the rules, also applies for restricting access to component methods.  If your gumball machine only allows holders of an admin badge to call a collect_coins method to pull the collected money out, that restriction is understood by the system, and callers do not have to explicitly pass in the badge.  If the appropriate admin badge is present in the authorization zone, the call is permitted.  If the badge isn’t present, the system instantly aborts the entire transaction.  Easy peasy.

What are the benefits of the new model?

There are a few big ones!

First and foremost, it allows us to expose the rules to off-ledger tools like wallets in a standard way which they can comprehend.  This enables clear communication to the user on the rules governing methods and resources, and permits clever wallets (like the one we’ll release!) to intrinsically understand whether the user can produce the necessary badges for access, and even present those badges in the transaction automatically.

Second, it’s just easier from a code perspective to not have to be fiddling with the badges directly when doing privileged actions.  You don’t need anything passed in.  You don’t need to specify what is permitting you to perform an action.  You just attempt the action, and it succeeds or aborts as appropriate.  It’s actually harder to explain than it is to use; in practice, it’s all magically delicious.

Finally, this approach means that we can also enable modification of the rules when instantiating a component from a blueprint. Want to use the Radiswap blueprint but have your component restrict the swap method to holders of your membership badge?  No problem.

It’s important to point out that we haven’t lost the primary advantage of our original authorization model: the whole system functions entirely without the need for a concept of “who is calling me.”  The design pattern of access control based upon knowledge of your caller is all but universal in the DLT space, and it’s not a good pattern!  It puts too great a burden on the developer to get it exactly right in a complex system of interoperable smart contracts, and it has led to the loss of hundreds of millions of dollars.  Once a developer gets their first taste of badge-based authorization with Scrypto, there’s no going back.

Details, details, details

Want concrete examples?  Wondering how we prevent authorizing things you didn’t intend?  Curious about how to handle complicated rulesets that require things like branching logic?  There’s a lot of detail we didn’t cover in this summary, so please see the related documentation for the good stuff.

Authorization isn’t the only big change to Scrypto that came with v0.4!  Please see the full release notes if you’re an existing Scrypto developer and want to know why your code suddenly stopped compiling.