Blockchain call extension

[nhynes]

Most blockchain functions map well to WASI except for call/transact, which is an RPC augmented with the ability to transfer the platform's native token (e.g., Eth) from the caller to the callee. It's possible to do this out-of band, but not efficiently: it'd require making two transactions, passing around receipts, and handling rollbacks/refunds.

As long as we're going the WASI module route, it might be worth adding a single function to the "blockchain" module to support Ethereum-like blockchains:

__wasi_blockchain_transact(
	callee_addr: *const u8,
	value: u64,
	input: *const u8,
	input_len: u64,
	fd: *mut __wasi_fd_t
) -> __wasi_errno_t;

• callee_addr is a fixed-length byte sequence with length known by the platform. For instance, Ethereum addresses are 20 bytes long.
• value is the amount of native token to transfer from the calling account to the callee
• input/input_len - a C slice containing the input to the transaction. input_len = 0 for simple balance transfer.
• fd - a capability to read the output of the transaction

The errno result would be

• success: ESUCCESS
• no account at callee address: EADDRNOTAVAIL
• insufficient funds for value transfer: ENOBAL (this one would have to be assigned a number
• anything else: application specific
• (running out of computation resources, or gas, is unrecoverable and results in the process aborting)

Upon ESUCCESS, fd would be of type SOCKET_STREAM and have read-only pipe
semantics.

This proposal would support most existing smart contract platforms including those with a synchronous RPC model (e.g. Ethereum, EOS) and those with asynchronous cross-shard RPCs (e.g, Near).

Note: left out of this call function, but perhaps desirable, is the amount of gas allocated to the sub-transaction. The alternative is to simply give the callee the full amount of remaining gas. One would presumably not call untrusted code, so there should be no need to limit gas for security reasons.

[devsnek]

why does this need to exist in wasi? i don't think a standardized api for cryptocurrencies is related to wasi's goals at all.

[nhynes]

i don't think a standardized api for cryptocurrencies is related to wasi's goals at all.

Where did I say cryptocurrency? Blockchain is a decentralized computation platform that benefits greatly from using WASI. As a modular systems interface, one would think that it's in the purview of WASI to consider modules for novel systems.

Please do not conflate (your personal opinions on) cryptocurrency and blockchain.

[devsnek]

the thing that is representing a transaction of tokens seems out of place for wasi. crytographic functions to create chained signatures seems like something that could be in a wasi crypto module.

[nhynes]

crytographic [sic] functions to create chained signatures

I don't see how that applies. A call in a smart contract platform is just an RPC with value. Unlike the input which is passed to the callee, the value parameter is handled by the runtime before the callee is executed. The additional information is why a plain socket won't work. This could be done at the application layer, surely, but it helps cross-chain interoperability if there's a runtime standard.

[devsnek]

ok so how I'm currently thinking about this is like, a js canvas api to draw a line vs a function that draws a histogram. Certainly drawing histograms is useful, and standardization would make it easier for everyone to draw histograms, but I wouldn't put that histogram function in the js canvas api. it appears to me that this transaction api with its ENOBAL is more of an analogue to the histogram function than to the line function.

[nhynes]

Okay, so imagine a world in which the canvas API were modular and the histogram function were in a plotting module. The plotting module would make it significantly easier for researchers to share results; everyone else could be blissfully unaware of its existence. That's what this proposal is.

If you don't like the name ENOBAL, it could just as easily be called ERUNTIME and multiplexed for use in, say, the CUDA module whenever that happens. If you don't like the idea of adding more errors at all, then we could work to standardize what existing error should be used (but then why make errno_t 16 bits?). However, the "call with value" functionality is as essential to blockchain as the equivalent method is to JS fetch.

At this point, we should wait for someone else in the subgroup who works with blockchain to chime in. This discussion is becoming one of whether you think blockchain WASI is useful, which is a separate matter entirely.

[devsnek]

to be clear, I don't doubt that wasi is valuable to the blockchain, or that this API is valuable to blockchain, I just don't yet understand why this api needs to be in the wasi namespace.

[nhynes]

why this api needs to be in the wasi namespace

Well, it wasn't meant to be in the namespace any more than the graphics or (eventually) bluetooth modules would be. The reason for proposing an optional module is that the function depends on WASI file descriptor semantics. A capability-based model is (un)arguably the correct way to architect a secure blockchain platform. Moreover the WASI async proposal, when it arrives, will be a perfect fit for RPCs in high-performance sharded/asynchronous blockchains.

Overall, we're seeing a mass movement of blockchain runtimes to Wasm. WASI is an excellent replacement for the ad hoc exports that are currently in use. A standard for blockchain applications would enable platform developers to collaborate on robust, shared runtime components and make it easy for users to leverage the unique features of each platform. I suppose, then, that the real question is how to streamline this process so that it does not disrupt the core standardization efforts.

[wanderer]

I think we can come up with a more general interface that can satisfy the of a blockchain embedding. The prerequisites probably should be broken up into separate issues, but here is the route I was thinking.

We should use wasm's funcRefs directly. And extend WASI's file APIs to be able to store funcRefs like files. instead of having callee_addr: *const u8, an Ethereum like blockchain embedding could use __wasi_path_open(root_fd, callee_addr/<entryPoint_funcRef>). After getting a fd to the entryPoint_funcRef there would have to be a corresponding methods to load the funcRef into the anyfunc table which would then allow caller to just use call_indirect. Gas and Value transfers could be added as independent interfaces. The Gas interface for example could look like

get_gas_budget

gets the amount of gas that will be spent when the function is called.

Parameters

• funcRef i32ref

Returns

• i32 the amount of gas to be spent

set_gas_budget

sets the amount of gas to be spent when the function is called.

Parameters

• funcRef i32ref
• gas i32

A capability-based model is (un)arguably the correct way to architect a secure blockchain platform.

I agree with this but Ethereum's model that allow any contract to talk to anyother contract complete breaks the capability model and we should avoid at all cost baking it into any interface.

[dumblob]

And extend WASI's file APIs to be able to store funcRefs like files.

File (or other tree-like, DB-like, ... you name it) access APIs might in the end not be part of core WASI (i.e. in the WASI namespace), but rather an optional module - pretty much as @devsnek already said above.

[wanderer]

@dumblob thats a good point, how to persistently store fds, funcRefs or any other capability should be independent of other associated interfaces

[dumblob]

how to persistently store

Not just persistently, but "store to a storage in any way" 😉.

[nhynes]

We should use wasm's funcRefs directly. And extend WASI's file APIs to be able to store funcRefs like files

Neat! I like this idea. Let me try to reiterate it to see if I have it right. Please correct me if I'm wrong.

import!(other_service.abi); // generates client impl

fn main() {
	let client =  OtherService::at(<address>); // -> path_open
	let params = Context::new().with_gas(42); // nothing yet
    let output = client.method(&params, arg1, arg2);
    //! -> obtain funcref, unpack params into funcref via external API, call funcref to get data
    // -> fd_close
}

Is this along the lines what you were thinking? One question: how does one actually get the funcref? The only output of open is an fd, so there'll need to be a way to get one from the other.

Another (unrelated question): we would ideally have something like WebIDL for a blockchain embedding. I've made an tool that automatically generates an IDL from rust source code. Right now it's a simple custom JSON format that can be used to generate a client. If you had any other ideas, I'm all ears.

[wanderer]

Is this along the lines what you were thinking?
it looks close

One question: how does one actually get the funcref? The only output of open is an fd, so there'll need to be a way to get one from the other.

yep! so currently the are 8 file types so we could just add another one func_ref and have methods for loading a fd of the type func_ref into the anyfunc table. so for example...

funcref_set : (slot : int, func : fd) -> ()
Where slot is the index in the anyfunc table to put the function references

funcref_get : (slot : int) -> (fd)
funcref_get would do the opposite and load a function reference from the anyfunc table return it as a file descriptor which could be saved with path_link

But this would change once we have reference-types, then we can have proper funcref and we would just an a casting functions from fd -> funcRef.

[nhynes]

Cool, makes sense.

methods for loading a fd of the type func_ref into the anyfunc table

Hmm, are these functions actually required? What if the funcref described by the fd were automatically loaded into the anyfunc table? I can't quite think of a scenario in which a module would want to obtain a funcref but not use it. Maybe if it wanted to hand the capability off to another module, but then why not just return the anyfunc ref directly? Indeed, if this were the case, we could already do something like this (associated .wat).

The only reason I'd be averse to more exports is because updating the WASI runtime requires hard forking, which is somewhat less than fun. That and it's nice to not maintain deprecated exports in perpetuity :)