| sidebar_position | title | description |
|---|---|---|
100 |
Meeting Notes |
Notes and recordings from the Soroban protocol & developers meetings |
- Stellar Asset List (SEP-0042) draft presentation by OrbitLens
- Stellar + Soroban documentation survey
- Plan and schedule for these meetings
- Protocol meetings every other Thursday at 4pm ET
- Developer meetings every other Friday at 1pm ET
- Will continue to adjust as needed
- Fee bump bug - announcement | discussion thread
- Fee sponsorship bug: unused fee is refunded to the inner tx source rather than the sponsor source.
- Fix in new release. Up to the ecosystem and validators to upgrade. The fix will likely be rolled out before Phase 2.
- 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.
- TxMeta Deprecation in Horizon - announcement
- Ideas around testing against ledger snapshots - request
- Define the needs a bit more clearly
- Definitely something here we should be addressing to make testing against specific ledger state easier
- How do you get a list of smart contracts? - thread
- Observe create contract ops as ledgers close
- Use an indexing service
- What is the status of contracts caching support? - question
- The need for zk-enabling encryption curves like BLS12-381. Github thread.
- Use cases that ecosystem is interestd in:
- 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
- Zkbricks wants to build an L2 system for that enables secret state for arbitrary smart contracts
- Skyhitz wants to use stellar for efficient compute, cost, and scalability while using zk to prove ownership of high-value assets on another chain
- Use case enumeration continues in the discord thread.
- Considerations for host function implementation
- 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.
- 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.
- Path Forward
- 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.
- ZkBricks and others will prototype locally and provide feedback.
- What are the best practices for managing transactions in the frontend, with respect to transaction ordering.
- Core devs confirmed that ordering is intentionally arbitrary.
- Request for an API for current version of the environment/sdk
- Github issue filed for the RPC to return versions of the current node.