Discord agenda thread

1. Stellar Asset List (SEP-0042) draft presentation by OrbitLens
   1. SEP draft
   2. Discord discussion
2. Stellar + Soroban documentation survey
   1. Take the survey

Discord agenda thread

1. The proposal is to advance stellar-core by adding a host function to verify the secp256r1 signature, which is the most common elliptic curve used outside of the blockchain space. It is useful in connecting off-chain authentication interfaces with on-chain functionality.
2. Note that the proposal is not for a new signer type but a host function.
3. Leigh investigated adding support for the WebAuthN use case, by allowing a custom account / smart contract to sign soroban auth entries using a secp256r1-signed payload.
4. secp256r1 is supported by phones, passkeys, and enables an app to replace passwords. This is a massive benefit to user-facing applications like wallets.
5. Pros and cons of the interface: blockchains generally implement the recovery interface over the verification interface but verification is easier for developers as it reduces burden on the client and the network.
6. The WebAuthN use case requires encoding and decoding of base64 payloads and decoding JSON blobs, which is not currently supported in Soroban.
7. While there are hacky ways of accomplishing the latter, it’s not a great developer experience and final implementation is susceptible to breakages on updates.
8. It is also costly to bundle decoding with verification in guest.
9. Soroban has always led with a batteries included mindset. Keeping in line with that approach, it makes sense to further investigate and determine whether a host function makes sense for these as well.
10. Leigh’s implementation may require further evaluation of the crates used for ecdsa and p256.
11. Brief discussion around proposed process for adding of a host function by a non-core dev.

Discord agenda thread

1. Plan and schedule for these meetings
   1. Protocol meetings every other Thursday at 4pm ET
   2. Developer meetings every other Friday at 1pm ET
   3. Will continue to adjust as needed
2. Fee bump bug - announcement | discussion thread
   1. Fee sponsorship bug: unused fee is refunded to the inner tx source rather than the sponsor source.
   2. Fix in new release. Up to the ecosystem and validators to upgrade. The fix will likely be rolled out before Phase 2.
   3. Up to validators to determine if they’d like to push the v20 upgrade date to wait for the fix; or upgrade with current release.
3. TxMeta Deprecation in Horizon - announcement
4. Ideas around testing against ledger snapshots - request
   1. Define the needs a bit more clearly
   2. Definitely something here we should be addressing to make testing against specific ledger state easier
5. How do you get a list of smart contracts? - thread
   1. Observe create contract ops as ledgers close
   2. Use an indexing service
6. What is the status of contracts caching support? - question
   1. response

Discord agenda thread

1. The need for zk-enabling encryption curves like BLS12-381. Github thread.
2. Use cases that ecosystem is interestd in:
   1. Excellar, i.e. folks that kicked off this conversation by submitting a PR for BLS12-381, wants to add a DAO-controlled oracle where the elliptical curve provides the ability to add new DAO voters
   2. Zkbricks wants to build an L2 system for that enables secret state for arbitrary smart contracts
   3. Skyhitz wants to use stellar for efficient compute, cost, and scalability while using zk to prove ownership of high-value assets on another chain
   4. Use case enumeration continues in the discord thread.
3. Considerations for host function implementation
   1. Core devs questioned whether BLS12-381 was the right curve and also highlighted the need to determine the correct level of abstraction given there is a tradeoff between flexibility and efficiency. Lower level of abstraction will enable more flexibility but result in more hot loops in the wasm while a higher level of abstraction will be highly efficient but will restrict generality.
   2. ZkBricks thought that there is a need to directly expose pairings and group operations without any level of abstraction. The space is in active development and flexibility is needed to try out new approaches and proof systems. From the point of view of crypto agility, it would be good to expose a generic interface that supports a variety of curves in the backend.
4. Path Forward
   1. Core devs mentioned crypto curves can be experimented locally by linking rust crates, which it turns out, had failed in the past. This will be explored and fixed.
   2. ZkBricks and others will prototype locally and provide feedback.
5. What are the best practices for managing transactions in the frontend, with respect to transaction ordering.
6. Core devs confirmed that ordering is intentionally arbitrary.
7. Request for an API for current version of the environment/sdk
8. Github issue filed for the RPC to return versions of the current node.