Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blockchain WASI #1

Open
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
3 participants
@nhynes
Copy link
Collaborator

commented May 23, 2019

@nhynes nhynes changed the title Create blockchain_wasi.md Blockchain WASI May 23, 2019

Show resolved Hide resolved blockchain_wasi.md Outdated
Show resolved Hide resolved blockchain_wasi.md Outdated
Show resolved Hide resolved blockchain_wasi.md Outdated
Show resolved Hide resolved blockchain_wasi.md Outdated
Show resolved Hide resolved blockchain_wasi.md Outdated
Show resolved Hide resolved blockchain_wasi.md Outdated

5.3 Environment

We expose the environmental variables

This comment has been minimized.

Copy link
@willscott

willscott May 25, 2019

Should also expose a variable expressing the version of the runtime.

This comment has been minimized.

Copy link
@nhynes

nhynes May 27, 2019

Author Collaborator

Not sure about that. The wasm module should request a particular version if there's versioning to be done, but having this available at runtime is just asking for trouble (c.f. python six)

This comment has been minimized.

Copy link
@willscott

willscott May 27, 2019

if semantics change in any way on version upgrades, this provides an escape hatch by which old contracts can shut down or force approval from an owner before continuing to allow txns

This comment has been minimized.

Copy link
@nhynes

nhynes May 27, 2019

Author Collaborator

Then why not expose an import that specifies a runtime semver? if it's not compatible, the program just won't run. If the author wants to really lock things down, she can set the semver to equality and then redeploy+migrate when a new runtime version is released.

This comment has been minimized.

Copy link
@willscott

willscott May 27, 2019

I don't think i care if it's an import or an env var, but we should specify how it's accessed and versioned as part of the RFC

This comment has been minimized.

Copy link
@willscott

willscott May 27, 2019

why not the inverse? version should be able to get into the contract in some way - especially since a static export you propose would be very different for a contract to update dynamically from storage.

This comment has been minimized.

Copy link
@nhynes

nhynes May 27, 2019

Author Collaborator

I don't think that the contract should know the version since that leaks implementation details. Ideally the contract would be self contained and depend on nothing other than entropy and storage. Either the runtime supports the contract or it doesn't. We should aim for the API to be as simple as possible.

This comment has been minimized.

Copy link
@willscott

willscott May 27, 2019

no api is static, and to not design the ability to modify it subsequently will cause it to fail, or other non-ideal things like block numbers to be used as indications of when API versions change.

We should directly expose api version, so that there's functionality by which contacts can track if they do/don't work.

This comment has been minimized.

Copy link
@nhynes

nhynes May 27, 2019

Author Collaborator

functionality by which contacts can track if they do/don't work

I humbly disagree. A contract has no idea what future runtimes will look like, so there's no reasonably way besides having heavily mutable contracts to accommodate new behavior. The owner should just terminate the contract and deploy a new one.

This comment has been minimized.

Copy link
@willscott

willscott May 28, 2019

I think version needs to be exposed. the other APIs of this type: eth / similar chains, linux kernel sys call interface, etc. all have it, and it's valuable.

Apply suggestions from code review
Co-Authored-By: Peter Gilbert <petergilbert@gmail.com>
Co-Authored-By: Will <willscott@gmail.com>
location for references to other contracts. Within these directories
the following files SHOULD be exposed:
* `code` - The code at that address, if any.
* `sock` - A file descriptor for cross-contract calls to that address.

This comment has been minimized.

Copy link
@willscott

willscott May 29, 2019

ideally would like to be able to express the distinction between cross contract call, and pure call- where all state viewable to the delegated call is transient

This comment has been minimized.

Copy link
@nhynes

nhynes May 29, 2019

Author Collaborator

I think that the real issue is that current tooling doesn't expose wasm imports/exports without annoying extern "C" functions. With enough codegen, anything is possible, but it's not straightforward and, even then, calling a function doesn't imply the runtime cost of the potentially cross-shard RPC that is actually executed.

This comment has been minimized.

Copy link
@willscott

willscott May 29, 2019

the other way to look at this is: can i learn semantics about a remote library/service to gain safety / does the calling program have any ability to run a program with constraints?

  • call this other service without the ability for it to generate logs
  • call this other service without the ability for it to read from / write to persistent storage
  • call this other service with an allowance of up to [x] gas

This comment has been minimized.

Copy link
@nhynes

nhynes Jun 12, 2019

Author Collaborator

Update: sock isn't the right abstraction since it doesn't have a notion of value transfer. Instead, a cross-contract call should be crated by __wasi_blockchain_transact which populates a FD that yields the output of the call.

@nhynes nhynes referenced this pull request Jun 13, 2019

Open

Blockchain call extension #56

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.