ipld / ipld

InterPlanetary Linked Data
https://ipld.io
Other
1.25k stars 165 forks source link

Webassembly Interface Notes #18

Open wanderer opened 7 years ago

wanderer commented 7 years ago

Webassembly DAG interfaces

related

https://github.com/ipld/specs/issues/35 https://github.com/ipld/specs/issues/38

Overview

This note presents an initial Webassembly interface for generic Merkle DAGs. There are two interfaces proposed here. 1) The translator (resolver) API which allows the wasm VM to parse links from binary data. 2) The Selector API allow for traversal of the graph and selecting of a subgraph

These interfaces are low level and should allow for upper layers to be implemented on top of them.

glossary

Rational

It would be conducive to implement Selectors and Transforms in webassembly so that 1) they can be loaded at runtime reducing the bootstrap binary size 2) enable universal implementations of Selectors and Transforms 3) reduces the trusted computing base 4) present an deterministic way to limit resource usage based on metering

Challenges

1) Its still the early days of Webassembly and Webassembly VM usage outside the browser is still largely uncharted territory 2) Language support is still limited to C/C++/rust although potential anything that llvm can compile can be used in a wasm VM

API Overview

Data types

We define the following Webassembly data types:

Tables

A table named 'callback' must be exported if any callbacks are used. All callbacks functions have a parameter of a single i32 which will contain the error code of the orginal operation. If there where no errors then the return value will be 0 other wise it will be 1. All operation that involve state look ups are asynchronous

Translator API

A translators maps some given data into method that can be consumed by the underlining IPFS implementations.

the Webassembly binary MUST export the following methods to be compatible DAG service. Like wise the host environment must also provided the following API to wasm binary that are intended to be translators. The translator's imports MUST use the namespace "translator".

createVertex

Creates a mutable vertex reference

Returns vertexRefence i32ref

createEdge

Given a link and some metadata this creates an edge.

Parameters

Returns edgeReference i32ref

addEdge

Adds an edge to a vertex given an edge reference and a label

Parameters

Selector API

Selectors traverses the graph and selects some subset of vertices. The Selector's imports MUST use the namespace "selector".

select

Adds a vertex reference to the array of reference to be returned

parameters

root

the root vertex of the DAG we are operating on

Returns

resolve

Given an edge reference returns a vertex reference

Parameters

Callback Signature

getEdge

Gets an edge reference given the edge name

Parameters

return

getEdgeDataLength

Gets the metadata attached from to an edge

Parameters

return

getEdgeData

Gets the data from an edge and writes it to memory

Parameters

getLink

Unwrap a link from an edge

returns

isNullLink

checks if a link is null or not Parameters

returns

Iterator API

This enables iteration of a vertex's edges

edges

Return

next

Advances the iterator

Parameters

getEdgeName

Parameters

getEdgeNameLength

Parameters

Return

wanderer commented 7 years ago

@jbenet @kumavis @nicola @diasdavid

wanderer commented 7 years ago

@axic

nicola commented 7 years ago

This is really interesting! I didn't have time to really looking into this, it is awesome to start working on this again now. The ideal would be, be able to compile the current resolvers into this language (or whatever candidate language) at some point, so no need to write the GO/JS parser.

axic commented 7 years ago

The libc on eWASM (soon to be uploaded) can be reused for this to compile C snippets.