Draft smart contract data CAP & PRs

[Graydon Hoare]

Hi,

The following draft CAP, core and contract-environment PRs cover an
initial proposed set of ledger entry and host function semantics for
data access in smart contracts.

https://github.com/stellar/stellar-protocol/pull/1218
https://github.com/stellar/stellar-core/pull/3439
https://github.com/stellar/rs-stellar-contract-env/pull/83

Feedback is very welcome. This work is downstream of several existing
CAPs (46 and 47 in particular) so there's a certain amount of
assumptions baked-in and a lot of dependent code in the PRs. Please
let me know if you have any questions.

Thanks,

-Graydon

[Leigh McCulloch]

This proposal is now at: https://stellar.org/protocol/cap-53

[Leigh McCulloch]

Hi Graydon,

The proposal makes a lot of sense to me. It's simple and the permission scheme is easy to understand.

func $contract_data_put (param $key i64) (param $val i64) (result i64)
func $contract_data_del (param $key i64) (result i64)

In the _put, _del host functions are the results a SCV_STATIC with value SCS_VOID, or some other type/value?

/// Traps if ... there is no such ledger entry.
func $contract_data_get (param $key i64) (result i64)

This is another situation where the contract SDK may end up calling _has before calling _get so that it can offer up an API that encourages developers to handle error conditions. This is another situation where the resulting WASM might benefit from introducing a None type or bit into SCVal so that we can reduce the number of host fn calls by one.

Each write is visible immediately within the issuing transaction, but not to any other transaction, until the writing transaction commits

Are writes also visible if re-entry occurs via a cross-contract call?

Thanks,

Leigh

[Graydon Hoare]

On Thursday, May 26, 2022 at 10:47:40 AM UTC-7 Leigh McCulloch wrote:

Hi Graydon,

The proposal makes a lot of sense to me. It's simple and the permission scheme is easy to understand.

func $contract_data_put (param $key i64) (param $val i64) (result i64)
func $contract_data_del (param $key i64) (result i64)

In the _put, _del host functions are the results a SCV_STATIC with value SCS_VOID, or some other type/value?

Yes, void. Good catch, I'll update the CAP to reflect this.

 

/// Traps if ... there is no such ledger entry.
func $contract_data_get (param $key i64) (result i64)

This is another situation where the contract SDK may end up calling _has before calling _get so that it can offer up an API that encourages developers to handle error conditions. This is another situation where the resulting WASM might benefit from introducing a None type or bit into SCVal so that we can reduce the number of host fn calls by one.

I feel the same counterargument applies here as with the other cases:

  - Users can forget to check error codes making contracts more likely buggy

  - Codesize increases on all happy paths because they have to now do check-for-none-and-trap

  - You get ambiguity between a successful get of `None` and an unsuccessful get

Is this case different?

 

Each write is visible immediately within the issuing transaction, but not to any other transaction, until the writing transaction commits

Are writes also visible if re-entry occurs via a cross-contract call?

Yes. Though I don't say so in the CAP; I'll edit to specify that. I think if we did not do so we'd be opening users up to fairly subtle stale-read bugs. I'm curious if you can think of a reason to not do so!

 

-Graydon