Announcing Protocol 21

1. Stellar is ahead of the curve in implementing innovative features that allow developers to create highly usable and secure projects, demonstrated by the introduction of secp256r1 verification in CAP-0051. Incorporating passkey signing capabilities aligns with modern security practices and simplifies the authentication process in smart contract transactions.
2. How vital community contribution is to the continued evolution of Stellar, as evidenced by the development and implementation of community-driven CAPs. Community members are empowered to propose, discuss, and refine new features and improvements to the Stellar network, as demonstrated with tdep’s work on CAP-0053, which adds features to improve state archival.
3. The ecosystem is committed to putting in continuous effort to maintain network efficiency and minimize fees. SDF’s mission is to create equitable access to the global financial system, and CAPs 0054, 0055, and 0056 strive to keep the Stellar network accessible and cost-effective for all users.

Let’s talk a little more about Protocol 21 and what each CAP will bring to the Stellar network.

CAP-0051: Smart Contract Host Functionality: Secp256r1 Verification enables support of secp256r1 verification in Stellar’s smart contracts via the exported host interface.

This is an exciting one! Secp256r1 is a common signature algorithm used in Webauthn, which is the standard behind passkeys available on browsers, computers, and phones. The approval of this CAP will enable secp256r1 verification, allowing developers to design contracts that incorporate passkeys to sign smart contract transactions instead of using passphrases or signing keys. Passkeys offer a faster, more secure method of identity authentication by using encrypted data stored on a device and performing user verification with biometrics (fingerprint or facial recognition). The use of passkeys for signing transactions remains largely unadopted in Web3 and is still a proposal for the Ethereum network, showcasing how Soroban is ahead of the curve.

If you want to see how using passkeys allows for an incredibly simple and intuitive web3 experience, check out SDF Ecosystem Engineer Tyler van der Hoeven’s pretty awesome passkey signing demonstration on X.

CAP-0053: Separate host functions to extend the TTL for contract instance and contract code allows for extending the time to live (TTL) for contract instance and contract code with separate Soroban smart contract host functions.

Soroban currently has only one host function that extends the TTL of the contract code and contract instance ledger entries by the same value. This CAP adds two new smart contract host functions: `extend_contract_instance_ttl` to extend the contract instance's TTL and `extend_contract_code_ttl` to extend the contract code's TTL. Introducing these two host functions allows the user to extend the contract instance and contract code separately, improving rent fee distribution.

Not only does CAP-0053 improve state archival functionality, but it was also created by Stellar community member Tommaso De Ponti (tdep)! Community contributions at this level are crucial to a thriving open-source culture and exactly the kind of thing that Soroban was designed to encourage. Check out the full and engaging CAP discussion on GitHub.

The next three CAPs take different approaches to ensure that Soroban transactions remain affordable:

CAP-0054: Soroban refined VM instantiation cost model refines the cost model for virtual machine (VM) instantiation.

Currently, CPU costs, linked to transaction fees, are primarily from VM instantiation. This refined model aims to charge fees that are closer to reality rather than overestimations, lowering overall costs and enhancing network scalability.

CAP-0055: Soroban streamlined linking lowers total cost by linking to fewer host functions during virtual machine (VM) instantiation.

There are over 100 host functions, and at present, all host functions are linked for every contract. CAP-0055 reduces these links to only the functions explicitly imported by the contract, lowering CPU costs per transaction, permitting more transactions per ledger, and boosting overall network performance by decreasing unnecessary workload.

CAP-0056: Soroban intra-transaction module caching lowers total costs by caching parsed Wasm modules within a Soroban transaction.

Currently, if a Soroban transaction invokes the same contract multiple times, each invocation re-parses the contract. By introducing a module cache, contracts only need to be parsed once per transaction, regardless of how many times they are invoked. This change allows for more transactions per ledger, improves throughput, and enhances performance by eliminating redundant parsing within a transaction's contract invocation tree.