15 posts tagged with "protocol"

After the Stellar Private Payments AMA, Jay Geng from the core team presented CAP-87. This is the CAP that audio problems pushed out of the previous week's discussion.

Why Post-Quantum Signatures​

The signature schemes that blockchains use today rely on the hardness of factoring and the discrete log problem, including its elliptic curve version. Shor's algorithm solves these problems in polynomial time on a large enough quantum computer. Nobody knows when that day comes, but Stellar wants to be ready.

A few months ago SDF published a three-stage quantum readiness plan for Stellar. CAP-87 is the first stage: add post-quantum signature verification to Soroban as host functions, so smart wallets can adopt a post-quantum scheme on their own. Network-level signatures are not part of this CAP.

Why ML-DSA​

NIST has three post-quantum signature candidates:

• ML-DSA (FIPS 204), lattice-based.
• SLH-DSA (SPHINCS+), hash-based. Signatures and keys are roughly an order of magnitude larger, and it is much more expensive to compute.
• Falcon, also lattice-based and more compact, but its standard is not final yet.

ML-DSA is the most mature choice. Large cloud providers support it in their KMS products, Cloudflare supports it, and OpenSSL and Apple's CryptoKit list it. Its signatures are a few kilobytes, which fits a blockchain much better than hash-based schemes. Jay noted that the other two could still come later, because the blockchain world is split on all three.

What CAP-87 Adds​

Three host functions, one per ML-DSA parameter set: verify_sig_ml_dsa_44, verify_sig_ml_dsa_65 and verify_sig_ml_dsa_87. They share the same interface: public key, message, signature and an optional context string for domain separation. The context must be shorter than 256 bytes, as the standard requires.

• The numbers 44, 65 and 87 refer to the size of the internal matrix. For ML-DSA-44 it is a 4x4 matrix of polynomials.
• Key and signature sizes are exact. For ML-DSA-44, the verifying key is 1,312 bytes and the signature is 2,420 bytes. Any other size makes the function fail at once.
• Each function decodes the key, decodes the signature, then verifies.

Costs​

The CAP adds nine new cost types, three per parameter set:

• Decode verifying key: constant cost. This step does more than parse bytes. The public key holds a seed, and the host expands it into the full matrix with SHAKE.
• Decode signature: constant cost.
• Verify: linear in message and context length, because the message is hashed together with the context and the public key. Everything else is constant.

Jay shared early calibration numbers for ML-DSA-44: about 38k CPU instructions to decode the signature, about 850k to decode the verifying key, and about 686k to verify. About half of the work is in decoding.

Questions​

• What makes it quantum safe: Lattice signatures rely on different hard problems, Short Integer Solution and Learning With Errors. Both come down to finding short vectors in a lattice, and there is no known efficient attack on them, even with a quantum computer.
• Which library: AWS has a formally verified implementation, but it is low-level C. The team prefers a pure Rust dependency. The two mature Rust options are RustCrypto and libcrux. RustCrypto is the likely choice: its code is simpler and cleaner, it is widely used, and its decode and verify steps are well separated. The interface does not depend on the library, so it can change later.
• Passkey smart accounts: ML-DSA is a new option, not a replacement. Passkeys today use secp256r1, and post-quantum passkeys need support from the platform and wallet side, for example in the WebAuthn layer. Jay warned against adopting it too early: if you give up hardware signing just to get a post-quantum property, that is a step backward. More ecosystem work is needed here.

Please add your comments to the CAP-87 discussion thread.

This week was planned as a protocol discussion on CAP-87 and CAP-88, with Jay Geng and Garand Tyson from the core team. Jay had audio problems and we could not hear him even after he rejoined, so this recording covers only CAP-88. Jay presented CAP-87 the next week.

CAP-88: Millisecond-Resolution Close Times​

Garand presented CAP-88, which he expects to be a straightforward change.

The problem: All ledger close times on Stellar are whole seconds. This has two effects:

• Two ledgers cannot close less than one second apart. Sub-second ledgers are still far away, but the limit is there.
• The network cannot target a ledger time that is not a whole number of seconds. With 5-second ledgers today, a small step such as 4.5 seconds is not possible.

The change: Close times move to millisecond resolution for consensus and validators. The time is the same, it is just not rounded to the second.

What stays the same: Everything a transaction sees still uses whole seconds. This includes the Soroban ledger timestamp, claimable balance predicates, time bounds and minSeqAge. The existing whole-second closeTime in StellarValue stays, and the new millisecond value is added next to it. Downstream systems that decode ledger headers must update their XDR definitions for the new union arms, but they can keep using the whole-second value, or pick up the new one. The near-term targets are steps like 5 to 4 or 3.5 seconds, so whole seconds are still fine at the transaction level. If ledger times get much shorter, the team may revisit milliseconds in the transaction interface.

Questions​

• Milliseconds for random numbers: Someone in chat suggested that milliseconds in the interface would help pseudo-random number generation. Garand and Dima disagreed. Soroban already has a PRNG on the host, and validators set the timestamp. A Byzantine validator could choose arbitrary millisecond values more easily than whole-second values, which are tied more closely to real-world time.
• Why not micro or nanoseconds: Network latency in a distributed system makes anything below milliseconds useless at the consensus layer. Stellar launched with whole seconds because ledger times were much longer at the time, and clock sync (NTP) and servers have improved a lot since then.
• Do validators need synced clocks: No. The validator that proposes a ledger includes its local timestamp in milliseconds. Clocks can still drift between validators, as they can with whole seconds today. The change improves the resolution, it does not require millisecond-level sync.

Please add your comments to the CAP-88 discussion thread.

This week's protocol discussion had two parts. First we wrapped up the CAP-84 debate from last week. Then Dmytro Kozhevin (Dima) presented CAP-86. Discord gave a few people audio trouble at the start, so if you could not hear Dima live, the recording above is the place to catch up.

CAP-84 Follow-Up: Why Muxed Contract Addresses​

Jake Urban, the author of CAP-84, joined to explain the product case. His core point: every valid reason to mux a G account also applies to contract accounts.

• Omnibus accounts: Most exchanges take deposits and withdrawals on G accounts with memos or muxed addresses. If an exchange or custodian moves to smart accounts, it loses both options, because a contract invocation cannot carry a memo.
• Per-payment IDs: On and off ramps attach an off-chain ID to a payment to reconcile it with the on-chain transfer. A muxed contract address can carry that ID in the address itself.

George restated his concern from last week. He does not have a strong objection, but he wanted the group to check if a Soroban-level pattern, such as a standard omnibus contract that emits the ID in events, could reach the same goal without a protocol change. He noted that the impact is smaller than he first thought, because integrators that read the CAP-67 unified events do not need the new strkey.

Jake's reply:

• A contract-level pattern would give each address type a different interface, which is a footgun for developers and would slow contract account adoption.
• Today you send a muxed deposit by calling the token contract directly. With a custom pattern, you would call the contract account, which then calls the token. That is a worse developer experience.
• Muxed G addresses already exist, so leaving contracts out feels like going halfway.

George agreed that fragmentation is a real concern and was fine with the decision once the alternative was considered. Dima added that a single address string is much safer than an address plus a separate ID. Users lose funds when they forget the memo, which is why muxed accounts exist in the first place.

A builder in the audience gave a real example. Their team won an SDF RFP for a smart account onboarding protocol. Today, on and off ramps cannot deposit directly to a C address, so they run a relayer: deposits go to a pooled G address with a memo ID, and the relayer forwards the funds to the user's contract account. Muxed contract addresses would remove that whole layer. With that, the group considered George's question about demand mostly answered.

CAP-86: Sparse Map Reads and Writes​

CAP-86 fixes a problem that Soroban has had since launch: you cannot change a #[contracttype] struct without breaking every reader of that struct.

The SDK uses fast host functions to convert structs to and from maps. These functions require every requested field to exist, and every field in the map to be consumed. If you add, remove or rename a field, the reader traps. The contract cannot catch the error and try another layout. People have hit this in practice: they upgraded a contract, added a field to the struct that holds the admin, and could no longer read that struct, so they could not upgrade again.

The CAP adds two host functions, sparse_map_new_from_linear_memory and sparse_map_unpack_to_linear_memory:

• Sparse reads: The reader names the fields it wants. The map can have more fields than requested. A missing field comes back as Void, which the SDK can map to Option::None. If you need a field, make it non-optional and the read fails as expected when the field is missing.
• Sparse writes: A None field is not written to the map at all. This saves storage and makes event payloads with many optional fields smaller. Dima mentioned SEP-41 events with an attached map as one use.

This enables migrations that were not possible before. You can add an optional field and fill a default when it is None, remove fields you no longer need, and extend structs passed between contracts without new functions. Dima compared it to protobuf v3, where every field is optional and the reader decides what is required.

Caveats:

• If two contracts disagree on a field name, an optional field could silently read as None. This needs a miscommunication and an optional field, so Dima considers it a small risk compared to the one it removes.
• Old readers break if a writer starts omitting None fields, because they expect every field. The SDK will decide when to use sparse writes.
• The CAP adds new functions and does not change existing ones, so no deployed contract changes behavior. To use the new semantics, you must update the SDK and rebuild your contract.

Performance is the same as the current functions, or slightly faster when you skip fields.

Please add your comments to the CAP-84 and CAP-86 discussion threads.

This week was a protocol discussion. Dmytro Kozhevin (Dima) from the core team presented two CAPs: CAP-85 and CAP-84. He started with CAP-85, because CAP-84 had already drawn some concerns and was likely to take longer.

CAP-85: Externally Managed Contract Executables​

CAP-85 came out of ecosystem requests. Every Soroban contract can already update its own Wasm, but only one contract at a time. If you run a fleet of contract instances that must share the same code, for example a set of token contracts, you need a custom batching contract today. That only works if the whole update fits into one transaction's resource limits.

The CAP adds a third executable type next to Wasm and the Stellar Asset Contract: an executable reference.

• The contract does not store its own Wasm hash. It points to a contract data entry owned by another contract, which the CAP calls the owner contract. You can think of it as a manager contract.
• Lookup gets one more step: find the reference, read the Wasm hash from the owner contract's entry, then load the code.
• When the owner contract updates the hash, every contract that points to it updates atomically. No need to iterate over the fleet.
• One manager contract can own many references, so a whole protocol with several different implementations can be updated in one transaction.
• Existing contracts can switch to an executable reference with an update, and they can switch back to a plain Wasm executable later. Nothing is one-way.

Safety: the executable tag​

A plain contract data entry could be deleted, or set to a value that is not a valid Wasm hash. A bug in a manager contract could then make the whole fleet unusable until someone fixes the entry. To remove that class of errors, the CAP adds a new object type, ExecutableTagObject, which wraps a string and must be used as the key of a reference entry. Because the protocol can now recognize reference entries, it:

• does not allow anyone to delete them, and
• only allows updates to the hash of a Wasm that is already uploaded on chain.

The only remaining way to break the fleet is to point it at valid Wasm that does the wrong thing, which the protocol cannot detect.

TTL extension and state archival​

The existing functions that extend the TTL of contract code will extend both the code and the reference entry when a contract uses a reference. The intent of these functions is to keep everything the contract needs to run alive, so extending only one of the two entries would be surprising.

The reference entry is persistent storage, so state archival works as usual. If it gets archived, simulation generates a restore, someone pays the restore fee, and the contract keeps working.

Questions from chat​

• Smart wallets and modules: A smart wallet could use a manager contract to update all of its modules atomically. Dima called this a good example of a use that the CAP did not originally target.
• Authorization context: Custom accounts receive a context that describes contract creation, so the CAP extends that structure with the new executable type. A policy could allow or block contracts created from a reference. This is a small backwards-compatibility point: an account that parses the context needs a newer SDK to read the new type. It only matters if the account itself creates such contracts.
• Alternatives: The team compared other designs and chose the one that is the most flexible and ergonomic for Soroban.

CAP-84: Muxed Contract Addresses​

CAP-67 brought muxed addresses to Soroban, but only for classic G accounts. A muxed address bakes an off-chain identifier into the address. A custodian such as an exchange can serve thousands of users from a handful of on-chain accounts, and the identifier appears in the token events.

CAP-84 extends the same idea to contracts. A muxed contract address is the 32-byte contract ID plus a 64-bit ID, and it gets its own strkey. The existing muxed address object and host functions cover the new type, so:

• SEP-41 does not need to change, and
• contracts that already accept muxed addresses pick up the new type automatically.

Is there demand?​

George raised the main concern in the discussion thread. The XDR change is small, but a new strkey type is a large ecosystem change. Every SDK, and every wallet or backend that handles addresses, has to support it. George asked for concrete use cases from builders, and asked whether Soroban's programmability could solve the problem without a protocol change. He gave claimable balances as an example of a feature that shipped before the need was clear.

Dima's answers:

• Jake Urban wrote the CAP and works with builders of custodial contract wallets. These builders want to integrate SEP-24 on and off ramps, but they cannot use memos or muxed destinations with contract accounts today.
• Memos are not safe in Soroban. Authorization is detached from the transaction on purpose, so you cannot reliably tie a memo to a given event.
• The other option discussed during CAP-67 was a new transfer function with a separate destination ID. That brings back the two-part address problem of memos, and every contract would need to change to support it.
• An account per user is expensive and hard to operate, especially for contract accounts. A custom wrapper token would bypass most of the ecosystem.
• Integrators that already parse the CAP-67 unified events get the muxed ID from the events without needing to handle the new strkey.

Dima's view: the CAP is not guaranteed to be merged, but if the protocol supports muxed contract addresses, this is the cleanest way to do it. George agreed that the implementation details matter and asked for a concrete picture of how a custodial contract account would work with SEP-24 without the CAP. The discussion moved to the thread and continued the next week.

Please add your comments to the CAP-85 and CAP-84 discussion threads.

Agenda: Discord thread

CAP Core team deliberated on the proposed CAPs:

1. Addition of a constructor to Soroban's flavor of Rust. CAP
   1. Team's concern was about potential break in compatibility, which Dima had addressed. There were no further concerns.
2. Addition of BLS12-381 curve and required field arithmetics - CAP
   1. Team's concern was about providing functions to check invalid input. It's too computationally expensive to do the check at the contract layer so the it may need to be implemented as a host function. Jay is seeking ecosystem input around use cases that require strict input validation.
   2. There were no further concerns.
3. Increase performance by upgrading Soroban's VM. CAP Discussion
   1. Team's comments were about accuracy of the measurement method but the demonstrated benefits of wall clock time were thought to be promising.
   2. There was a suggestion to expose performance improvements to contract developers thus creating the incentive to optimize contracts to leverage the improvements.
   3. There were no further concerns.

Discord agenda thread

Core Developers discussed the latest proposals to advance Stellar Core in this week's Protocol Meeting.

1. The proposal for addition of a constructor to Soroban’s flavor of Rust was introduced in a previous protocol meeting (previous meeting), documented in CAP-58. A constructor is a function that will only be executed the first time the contract is created.
2. In this meeting, Dima discussed the updates made since the last meeting:
   1. Default constructor - if a constructor is not defined explicitly, the contract is treated as if it has a constructor
   2. Semantics of the return value - if the transactions succeeds, it is required to return a valid value
   3. Constructor interaction with custom accounts - custom accounts must be aware of the context that they are authorizing.
3. Graydon discussed the upgrade to the Wasmi virtual machine, documented in CAP-60. Wasmi works by translating WebAssembly code to to an Internal Representation (IR) and then executing it. The upgrade is impactful in two ways.
   1. Translating from WebAssembly to IR takes longer but the execution of the resulting IR is performant.
   2. The upgrade introduces lazy compilation. Of all functions in a contract, only ones that are called in a given transaction will translated thus reducing both latency and fees.
4. Jay discussed addition of BLS12-381 cryptographic curve, documented in CAP-59.
   1. Addition of pairing-friendly elliptic curves enables zk-based applications. 11 host functions have been added to expose mapping, pairing, and arithmetic on the BLS12-381 curve.
   2. Examples case of BLS signature verification was presented. It consumed 26M instructions (running natively), which is promising given the per-transaction limit is 100M.
   3. There was general agreement that the interface is the right one as it allows a contract developer to implement a wide variety of use cases. Discussion continues in discord.
   4. Jay requested that developers should build applications against the function and give feedback.

A Core Dev, Dima, discussed the proposal to add constructor support to Soroban, Stellar's smart contract system.

Relevant links: Draft CAP, Ongoing discussion, Motivating Discord Thread

Key points discussed:

1. The proposal improves usability of Soroban for contract and SDK developers. A constructor guarantees contract initialization thus reducing overhead contract code that's usually added to ensure initialization.
2. There was general agreement for the proposal, questions were primarily implementation-focused like whether constructors should handle arguments, what should happen with upgrades, backwards comptability with contract creation functions, and behaviour on wasm update.
3. The high impact topic of naming is put to ecosystem vote, please cast yours here.

1. Garand discussed changes to the State Archival proposal based on feedback received at Meridian 2023. The proposed changes are:

• Previously, a downstream system called the ESS (Expired State Store) would store expired entries. In the new proposal, There is no ESS. All Archived entries, as well as all information required to generate restoration proofs for those entries, is stored directly in the History Archive.
• RPC nodes can generate proofs for archived state during preflight
• Captive-core can be directly queried for archived state, meaning that RPC/Horizon instances can potentially service queries for archival state

2. The draft proposal
3. Ongoing discussion
4. Snapshot size is TBD; it's a function of bucket list size as well as memory and historic demands placed on the RPC.
5. Bloom filters are the likely solution for proof of non-exitance though they come with trade-offs. They enable fast and cheap lookup but are probabilistic not deterministic.
6. Further comments are welcome.

Piyal from Freighter discussed the proposal to standardize the wallet interface. Key points from the discussion are captured below. For full notes, please view the recording; and also refer to the proposal and the post on github discussions.

1. The draft proposal
2. Ongoing discussion
3. Requiring the network passphrase might be uneeded complexity.
4. Both WalletConnect and mobile wallets likely have significant differences than the proposed interface (which is targetted at browser extension wallets); and thus likely require a separate SEP. The said SEPs should be created by teams working on wallet integration with the said platforms.
5. What is the role of the Stellar Wallet Kit in the ecosystem and how does it play with the standard itself?
6. As next steps, Piyal will incorporate the suggestions from the ecosystem into the proposal.

Agenda thread

1. The Standards Working Group proposed changes to the SEP process that empower the ecosystem by making the current process more decentralized and ecosystem-friendly.
2. The process has already been used for several proposals over the last three months.
3. Esteblock from Soroswap shared their journey of participating in the proposal for Asset List (SEP-42) and implementing the proposed standard
4. Discussion continues in the proposal doc.
5. Next step is to get further ecosystem feedback then update the Github SEP repository with the updated SEP process.

Discord agenda thread

1. CAP Core Team deliberated over the latest proposals put forth by the Stellar ecosystem to advance stellar-core.
2. Nicholas and David from the CAP Core Team listened to the following proposals and discussed the proposals with the authors. a. CAP Core team will deliver their vote over email.
3. Proposals discussed:
   a. CAP-51: add support for secp256r1 verification; by @leigh
   b. CAP-53: create separate functions for extending the time-to-live for contract instance and contract code; by @tdep
   c. CAP-54: lower total costs by refining the Soroban cost model used for VM instantiation into multiple separate and more-accurate costs; by @graydon
   d. CAP-55: lower total costs by linking fewer host functions during VM instantiation in Soroban; by @graydon
   e. CAP-56: lower total costs by caching parsed Wasm modules within a Soroban transaction; by @graydon

Discord agenda thread

1. Tommaso (@tdep) proposed a core change to allow for extending instance and code TTL with separate values on the host environment to allow for more cost-efficient designs a. Proposal and discussion are captured in github discussions stellar-core#1447
2. Tommaso received feedback on the proposal as well as implementation. Since it didn't require a metering change, core devs thought it to be a quick change.
3. The ecosystem voted in favor of the proposal by upvoting the post on Github Discussions. 13 votes were recorded.
4. As next steps, a CAP will be authored to capture the proposal and put forth for approval from CAP Core Team.