diff --git a/meeting-notes/2024-08-22.mdx b/meeting-notes/2024-08-22.mdx new file mode 100644 index 000000000..394d44f1b --- /dev/null +++ b/meeting-notes/2024-08-22.mdx @@ -0,0 +1,26 @@ +--- +title: '2024-08-23' +authors: naman +tags: [protocol] +--- + + + +[Discord agenda thread](https://discord.com/channels/897514728459468821/900374272751591424/1275577430043525204) + +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](https://developers.stellar.org/meetings/2024/07/25)), documented in [CAP-58](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0058.md). 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](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0060.md). 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](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0059.md). + 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.