.svg)
Scrypto v0.5 has been released today, bringing a first implementation of fees, support for owned components, human-readable addresses, and an assortment of below-the-fold changes and enhancements. These changes are primarily of interest to our bold, early-access community developers, so this post will be at a more technical level than is usual and some concepts will require basic knowledge of Scrypto. If that isn’t your cup of tea, no hard feelings if you close the page now – or perhaps you’d like to get started learning Scrypto!
Fees
Hopefully you have already read the explanation of the Babylon fee model, which outlines how the overall system will work. In this release of Scrypto, all transactions will need to pay for their execution to get developers used to incorporating this into their operations. Fortunately, XRD is free in your local environment and on the Public Test Environment, and Alphanet will include a free-to-anyone faucet for acquiring XRD. For the majority of test scenarios, you can simply add a call to the lock_fee method of the appropriate Account component early in your transaction manifest (in fact, this is exactly what resim does on your behalf when using it to run simple transactions).
You can check out the developer documentation around fees for more details and some examples.
For those awaiting details on how the royalty system will work, you may have noted that payment of royalties to blueprint and component creators will utilize this same fee mechanism. However, none of the systems for defining, collecting, and distributing royalties are in yet. Fear not, this is still coming.
A final reminder on fees: the fee table shipping with v0.5 was generated pseudo-randomly, and is only present for the purposes of testing that the collection mechanism operates correctly. It does not represent correct relative costs between different operations, nor correct overall transaction costs, so don’t read anything into any particular fee number you see there. The first tuning pass of the fee table to determine semi-realistic numbers will not take place before Betanet.
Owned components
You’re now able to have components as members of other components, which are not globally addressable and can only be accessed from within calls to their parent components. This lets you effectively have private components without worrying about setting up access controls for them. This is great for building more logically modular dApps for better understandability and reusability without introducing security concerns.
Calls to instantiate now simply return a Component you can store wherever you like, or you can then call globalize to push it into global address space and get a ComponentAddress back.
Documentation on owned components is available here.
VSCode support for transaction manifests
Users of VSCode need no longer suffer through dreary, monochrome transaction manifests! You can install a shiny new extension from here, or do an extension search for “Radix Transaction Manifest Support” and experience the joy of syntax highlighting, code formatting, error detection, and other goodies.
The extension is still at an early stage of development but is one of those things that you can’t live without once you’ve started using it.
And more!
Bech32 addresses with human-readable portions have been added, making it easy to distinguish between different address types by eyeball when debugging.
Some community developers have requested an alternative to Decimal when precision is highly important; you’re welcome to now use PreciseDecimal with our compliments, which supports 64 digits after the decimal point (Decimal, which is used for all resource amounts, supports 18).
Speaking of types, safe integral types have been added up through 512 bits, signed and unsigned.
New macros for simplifying calls to external blueprints or components without needing to export an ABI are now available, check out the related documentation.
Non-fungible resources now allow any SBOR value for IDs, which opens up some flexibility for developers who want meaningful identifiers.
Proof handling within Scrypto has changed a bit, too. In v0.4, many devs were submitting examples which passed Proofs of NFTs by intent, and then within their method they were only looking at the NonFungibleId and not verifying that the Proof matched an expected resource address. In Scrypto v0.5, Proofs passed into a method need to be validated by confirming the associated ResourceAddress before they will surrender details about their contents. Of course, if you’re sure you know what you’re doing, you can forcibly bypass this validation step, but you’ll have to do it explicitly. Have a peek at this example for how the new approach looks in action.
That rounds out the major changes for v0.5. Please be sure to check out the migration page if you find that your v0.4 code is no longer building.
Next step, Alphanet!
Public Test Environment update
Due to the ongoing portfolio management challenge, the PTE will remain on version 0.4 until the challenge has concluded, and will not be upgraded to use Scrypto v0.5 until August 31st.