Author | Maksym Zavershynskyi | medium.com/nearprotoco…

This article was published in July 2019. Two years later, it was like the Huashan Sword contest at the Hero conference, where top masters competed and argued academically, which also verified everyone’s optimistic outlook for Wasm in the future. The projects that are already using Wasm mentioned in this article have contributed to the Wasm ecosystem (technical documentation, code) so much so that they serve as case studies and templates for subsequent developers and teams that join the Wasm ecosystem.

Body:

For those interested in Wasm and blockchain but unable to attend the workshop in Berlin (avive.github. IO/WASM_on_the…

eWasm

Alex Beregszaszi @ eWasm Team

Alex delves into the story of eWasm. The project began in 2015 to find a better VIRTUAL machine for Ethereum. At the time, they had an idea that blockchain would run in browsers, or at least in light clients. However, many candidates (such as LLVM IR, a low-level Languange, which is an instruction set like RISC) were rejected because they were not optimized for portability. The choice lies with Wasm, but they want it to be fully compatible with EVM — supporting the same functionality and allowing contract interaction between Wasm and EVM. They also want to eliminate the need for EVM precompilation and implement them in Wasm.

By 2016, they had implemented metering implementations, from EVM to the Wasm compiler, JS implementations of eWasm for browsers, and C ++ implementations. But in 2017, they hit their first hurdle — eWasm must be synchronous due to EVM compatibility, but EthereumJS (Ethereum’s JS implementation) uses asynchronous methods for storage interaction; In addition, the Wasm JS API for browsers does not support asynchronous functionality. So they tried to solve the problem of synchronous and asynchronous incompatibility, resulting in the creation of Primea, which was later adopted by Dfinity. Unfortunately, Prima is too different from eWasm to apply to Prima anymore.

After the project stalled in 2017, they abandoned the in-browser idea in 2018 and adopted a synchronous approach. At that time they found information about JIT Bombs and a 300-byte chrome-specific JIT bombs (represented as Wasm bytecode) by exploiting Chrome V8 implementation details.

They also decided to narrow the scope of eWasm to pre-compilation that only needed to integrate with 5 host capabilities, rather than 25 host capabilities. In addition, they want to avoid metering injection in precompilation and use static analysis to estimate costs. However, the pause problem prevented them from doing so. This led them to rethink the interpreter rather than the compiler.

In 2019, they found that highly optimized EVM bytecode could achieve near-raw speed. After implementing the Bignum library for 256 operations in Wasm, Wasm is close to EVM.

Current focus: eWasm now focuses on the interpreter and minimal execution engine that uses only five host functions, with the biggest problem being cross-shard communication.

Precompilation problem

Casey Detrio @ eWasm team

Casey’s talk covered several related topics: moving from precompilation to Wasm; Using compiled Wasm with interpreted Wasm; And how his team can make interpreted Wasm as fast as EVM in cryptographic mathematics.

In theory, precompilation is a form of EVM bytecode that can implement certain special cases and reduce gas costs. In fact, it is implemented locally by the Ethereum client. Currently, there are eight pre-compiled ethereum clients, four of which were added at Genesis and four in October 2018 to support 128-bit operations related to SNARK.

Unfortunately, precompilation causes some problems:

They extend and complicate the trusted code base, make the precompiled GAS mechanism difficult to implement, and introduce errors. They require added social consensus, and each precompilation encourages more lobbying.

If they can solve the problem quickly enough, Wasm might seem like a solution. Unfortunately, none of the Wasm engines allow 10-point pairing under block GAS limits. However, a two-point match is possible. As Alex discussed in his last talk, they decided to interpret Wasm as a stepping stone.

There is debate as to whether the Wasm compiler or Wasm interpreter should be used. At its current stage, Wasm is not fast for cryptocurrencies. Unfortunately, the Wasm compiler is too complex and has too many dependencies to be incorporated into the code base by social consensus. Parity is working on a compiler that might be simple enough. On the other hand, the Casey team is working to improve the performance of the Wasm interpreter.

Wabt and EVMOne provide comparable performance on 64-bit arithmetic right out of the box. With a lot of optimization, WABT can even be close enough on 256-bit multiplications, but it requires a Bignum stack. The Bignum stack is a virtual stack that is manually operated through the host functionality. Current focus: Close the gap between wABT and Evmone + Weierstrudel for 128-bit multiplication. Since most smart contract code is business logic, there is some debate as to whether the Wasm interpreter should even focus on encryption. But there’s a huge demand for math like SNARK’s, so they’re looking at it right now.

Is Wasm a good fit for blockchain?

Paul Dworzanski @ewASM team

Paul talked about the challenges of implementing smart contracts on blockchain.

The first challenge is certainty. With Wasm, this can be addressed by avoiding floating points and being careful with memory growth, host functionality, and execution program implementation. This can be partially resolved by having the block proposer execute all major implementations of the Wasm executor and, if there is disagreement, remove the block.

Another challenge is Bombs. Bombs are entered into the Wasm engine, running out of time or size. There may be 20KB of nested loop code, resulting in 2.5 seconds of compilation on Chrome V8. You can also use special shorthand notation in Wasm to expand the 10 bytes of Wasm into 8GB local variables.

The biggest challenge is measurement. Unfortunately, the injection of gas metering intentionally prevents optimizations from being performed, which can often also be done by performing functions called by the host. Fortunately, eWasm has created a (github.com/ewasm/senti… 1.05 to 2.4 times. Interestingly, in special cases, the use of handwritten metering functions rather than host calls can improve. In addition, it is an interesting idea to use precise metering formulas for certain functions, such as kECCAK256.

With regard to bytecode size, depending on the optimization level, Wasm can match or beat EVM if we use blake2b as a benchmark.

Current focus: At present, it is acknowledged that the biggest bottleneck is not business logic, but encryption algorithms, especially mathematical algorithms related to SNARK. See Alex’s talk on how to use the Bignum API for improvements.

Ethereum 2.0 implementation

Casey Detrio and Alex Beregszaszi @ewASM team

Casey and Alex discussed the ethereum development phase, the complex decision-making process between the research team and the Runtime team, and the high-level concepts of the execution environment.

The design of Ethereum 2.0 implies the following separation that needs to be agreed upon:

(1) Trading order; (2) The result of executing the transaction.

Unfortunately, as of spring 2019, research is still stabilizing, and it is unclear how the protocol will be implemented (2), which is a barrier to the Design of the Runtime. As a result, the Runtime team faces the following unresolved issues:

• Should we use a stateful contract or a stateless contract? Stateful contracts require State Rent, which is harder to enforce, but easier to think about. The advantage of stateless execution is that the wallet does not need to be kept online at all times.
• Immediate or delayed execution of the contract?
• Is there a difference between the executor and the verifier?
• How do cross-shard calls work?

In addition, the eWasm team realized how cross-fragment messages could be delivered out of order.

Because of the unanswered questions and awareness of the cross-information, the eWasm team decided to narrow the scope, to the extent that they ignored how (1) and (2) were separated and the exact way the order of transactions was agreed upon. In this new scope, performers receive chunks of data (more than a more concrete set of transaction-level abstractions) that run through an execution environment (more than a specific EVM or Wasm virtual machine abstraction).

The execution environment may have the following specialties:

• Ethereum 1.0 block validator;
• Pure Wasm EE (eWasm 2.0 Smart Contracts changed to Execution Environments);
• Pure Wasm EE with cross-shard communication.
• SNARK/STARK validation;
• Various witness codes required for stateless execution, such as SSZ local code.

These execution environments will run on Wasm, so we’ll have EVM running within Wasm, and Wasm running within Wasm. The implementation environment interface will then use five host functions (ethresear.ch/t/phase-2-e… Contracts to run on Wasm EE. The Ethereum environment interface will then provide about 33 advanced features (github.com/ewasm/desig… .md), these functions are also available through the Rust API (github.com/ewasm/ewasm…

Current focus: eWasm team has achieved is called Scout EE prototype, please see: HTTPS: / / github.com/ewasm/scout. Scout defines the execution environment interface, test formats and tools, provides sample EE, and provides EE benchmarks; And Rust only has 400 lines of code! To do this, the eWasm team needed to address the following questions:

• Implementation environment interface;
• Fragment ETH transfer;
• Fragment call;
• Cross-shard invocation.

Solvable problems:

• Cost;

• Repeater design (a repeater is a repeater that relays transactions between users to a validator/actuator).

Wasm system interface

Lin Clark and Till Schneidereit @mozilla

Lin and Till speech is largely in WASI announcement blog (hacks.mozilla.org/2019/03/sta… Updated information on new changes in the direction of WASI development. This summary will focus on material not covered in the original blog post, so if you are not familiar with WASI, you need to read it first.

Now that we have the Wasm Runtime running Wasm outside the browser, the Wasm team is worried about falling into the same vulnerabilities as Node. Nodes allow JS to run outside of the browser, but in many cases, out-of-browser applications still need native modules, either because they perform better than non-native modules, or because you have code from another language that you want to reuse.

Unfortunately, native modules are not portable or secure, so Node made an early decision to allow non-native JS modules to access system interfaces, such as reading and writing files. As a result, now that we have written a lot of code for Node using a LiBc-like interface, it will be difficult to revert to a more conservative interface for security and portability.

Node falls into another loophole because Node doesn’t actually support the only Runtime that runs JS outside of the browser, so when you write JS, you know the API to use, which basically makes Node the standard outside of browser JS. With WASI, we want developers to know which apis are available, but not because one Runtime is dominant.

WASI enables Wasm for a variety of applications outside of the browser: CDN (Content Delivery Network), serverless, edge computing, blockchain, Internet of Things, portable CLI (command line interface) tools. For example, Fastly CDN serves a large portion of global Web traffic, and they are moving from a simple file per request to the code that runs the customer. It is feasible for them to create and remove instances on each individual request, as it takes 60 microseconds overall and 30 microseconds to instantiate the module. For comparison, Chrome V8 takes about 5 milliseconds to instantiate the JS module. In addition, Wasm is more scalable in order to be faster than JS. The Runtime for Fastly requires only a few kilobytes of memory overhead, while the JS engine for comparison requires tens of megabytes.

WASI takes a modular approach to interfaces. Initially, it began with the introduction of the WASI-Core module, which would override most POSIX. However, it also had to introduce other modules; for example, not all POSIX systems support process forking, so they created the WASI-Processes module specifically for systems that do.

WASI wants to define high-level object-based interfaces to be used with specific use cases, such as smart contracts. Then, if developers are using some kind of modular API, they can have the same Niche toolchain, such as environments and debugging tools. You can also have a Runtime tailored to a particular use case, rather than a cookie-cutter solution.

The WASI team is also working on supporting WASI’s Runtime, WASMTime. They want WASMTime to be the best Runtime for all devices: iot devices, cloud, blockchain.

Current focus: Move away from WASI-Core by splitting it into separate modules: file systems, random numbers, clocks, etc. For example, this would enable random numbers to be used by IoT devices that do not support file systems.

Wasm goes beyond browsers

Dan Gohman @ Mozilla

Dan gives an overview of WASI and its history, then he further discusses modular systems and access control models.

As Lin and Till explained before WASI tried to build a complex, yet generic, security model through access control. Anything the Wasm module tries to access needs to be granted externally by the host or another module. For example, in the WASI module, the directory cannot be accessed through the file path, so the directory file descriptor must be given somehow. Directory handles can come from the open mechanism or from opening another directory in another directory.

However, WASI is unlikely to support A mechanism for merging access, for example, if A module has read access to A directory and /A write access to A directory, /A/B will not be able to merge these into A handle with read/write access to /A/B. WASI then applies the same access model to sockets by treating urls like file paths. Unexpectedly, WASI also plans access control for random numbers, clocks, proc_exit, and more.

Dan also stressed the importance of modularity in WASI. He confirmed what Lin and Till had said that WASi-Core would be broken up into modules. Usually, WASI apis are just imports, and they don’t have to come from the host, they can come from another module. Therefore, if the host does not provide access to random numbers, the module can provide implementations of pseudo-random numbers for its submodules. However, this alternative functionality is not implemented.

Dan discussed the different categories of modules:

• The Command. Do only one feature – only main features, no extras. The lifetime ends when main exits;
• Reactor. There is no main function and it still exists after the Settings function is called. Exportable API. Useful for asynchronous I/O;
• The Library.

This classification will make the use of modules intuitive. Currently, the Wasm toolchain only supports the Command module.

Dan also talked about standardizing the blockchain API through WASI, however, he recognized that the blockchain API is currently so diverse that it is possible to standardize only one part of it, such as KV (key-value) storage.

The beauty of the WASI module is that we can iterate over it. For example, we can propose some WASI-KV modules now, and if we decide to change the API later, we can create another module with a different name, such as WASI-Kv2, and create a library wasI-Kv2 on top of WASI-KV. This gives us confidence in trying to standardize apis. A member of the audience expressed concern that KV storage might not be standard enough even for blockchains, as some of them try to operate on memory pages instead.

Current focus: emphasis on modularity and portability. Unify sockets, files and other streaming media content. Although locations in files cannot be generalized to sockets, more work needs to be done.

Design WasmRuntime for blockchain

Syrus Akbary @ WASMER.io

Syrus gave a brief overview of Wasmer, then focused on blockchain-specific features such as metering and blockchain API standardization.

Wasmer is a wrapper around multiple Wasm backends: Cranelift, LLVM, and Singlepass. Together, these backends provide a trade-off between compile time and runtime speed, with Singlepass having the fastest compile speed due to numerous optimizations, while LLVM has the fastest runtime. Wasmer also provides embedded languages for use in upcoming Go (used by Perlin, Cosmos, Ethereum), Rust (used by Polkadot, EVM), Python, Ruby, Wasm backends are used in languages such as C/C ++ and Java.

Wasmer has been working to speed up measurement. The difficulty is that metering should be deterministic, regardless of the back end. Today, the standard metering method is one that Parity implements, in which they convert the Wasm module by injecting calls into the gas meter on the host.

Wasmer introduced a new level of abstraction — middleware, which injects instructions during the parsing phase of the compiler. It also more aggressively inlines metering, rather than not calling the host before each operation, their metering calls the host simply get a gas threshold that saves them as used variables throughout the code, thus reducing the number of calls to the host. This resulted in an eight-fold reduction in metering overhead.

Wasmer is also working to unify the API of the Wasm module. They introduced contracts (not to be confused with smart contracts), which are basically a set of imports and exports required in a module, expressed in a lisp-like format. The contract plan is widely used in its package manager, WAPM, which will be distributed through IPFS.

Wasmer started the discussion of a unified smart contract API by proposing two approaches: The first is Oasis in this blog (medium.com/oasislabs/b… POSIX class imports available in WASI modules to simulate block linking ports; The second approach is to use an import without WASI (the eWasm approach) or a special WASI module for the blockchain. Readers prefer the second approach and cite Ben Laurie’s comment blog on WASI (medium.com/@benlaurie_… POSIX. Till Schneidereit of WASI confirms that it makes no sense to emulate POSIX interfaces for WASI contracts, but it might make sense to define high-level apis specific to small use cases using a modular system.

Current focus: ARM support, more language embedding, layered functionality — Wasmer should identify hot features and replace them with more optimized code.

Blockchain Wasm Stack — Use cases and requirements

Fredrik Harrysson @ Parity

Fredrik discusses how the requirements of smart contract code and Runtime shape some of the decisions they make on Parity. At the end of his talk, he and the audience debated the standardization of smart contract apis.

Parity was the first to create a public, unlicensed blockchain to run Wasm — Kovan. Unfortunately, no one has really used it, mainly because the contract language PWasm is terrible. End users and even contract developers don’t care if Wasm is running something, but contract developers do care about the development experience. Learning from PWasm, they created INK! — eDSL for smart contracts written in Rust. Parity considering ink! As a production-grade smart contract language, PWasm is more like a proof of concept.

Parity is first and foremost about security, which is why they use the Wasm interpreter and not the compiler. In general, the Wasm interpreter is pretty bad at matching EVM speed, but the compiler has multiple problems: Bombs, heavy dependencies, large attack surface, different priorities (Cranelift developers didn’t really determine deterministic priorities), etc. The compiler also has problems with metering. Suppose we use a compiler, and at some point, compiler updates release optimizations, can we reduce the gas cost of the corresponding operation? As the ethereum hard fork recently showed, changing gas costs is actually a huge security issue.

Fredrik also explores three dimensions of smart contract requirements: trusted and untrusted code, code size and speed. These sizes and the Wasm contract present some challenges. It’s hard to trust the Wasm code uploaded by the user as it may contain Bombs, but he suggests that even if we use a compiler (rather than an interpreter), there may be a game theory mechanism in which someone guarantees that the code does not contain Bombs if bombs are cut. He also supports the idea of eWasm to pre-define the costs of precompilation to avoid compilation.

Scale is a huge issue with Wasm smart contracts. Ethereum 1.0 has a size limit of 24KB and most Solidity contracts are in the hundreds of bytes. On the other hand, Rust smart contracts compiled into Wasm are 10 times larger. Currently, this is addressed by developing miniaturization tools, and it is possible to deploy an equivalent standard library on the blockchain.

Speed is another challenge for Wasm if we want it to match Geth speed. Geth uses some highly optimized code, for example the B128 library Geth gets from Cloudflare is a semi-written assembly tuned for x86-64. If we want to allow SNARK and other heavy encryption on Wasm, then things like hashing and elliptic curve pairing should be done in microseconds or billionths of a second.

Finally, Frederik discussed standardized smart contract apis with the audience. Fredrik is excited about having a SMART contract-specific WASI module, but is not sure it will be fully completed within the next 20 years. Until then, we can standardize some parts of the API. Some of his colleagues were skeptical about relying on WASI because they needed to ship before WASI was ready.

Wasm compiler – Lightbeam

Jack Fransham@Parity

Jack took a brief look at Parity’s new streaming compiler. Much of the detailed information related to specific low-level issues with Wasm and assembly has been omitted from this summary.

In general, in the blockchain world, there is a clear preference for interpreters and streaming compilers over more complex compilers. There are many problems with more complex compilers. Other problems Jack raises include that complex compilers have long compilation times, which means users have to pay for them. However, we also need a function to compile the price, which we might also need to price if the function itself is complex.

On the other hand, using an interpreter or streaming compiler, we can execute Wasm as soon as we finish reading. Using the interpreter, this can be done by executing Wasm directly. Using the streaming compiler, we can emit assemblies when we read Wasm and use it to execute the binaries immediately. However, the interpreter has several advantages: it is easy to build, easy to maintain, easy to debug, easy to ensure correctness, easy to write simple apis for end users, easy to swap code at Runtime, 100% memory safe, 100% thread-safe, portable between platforms. The main advantage of streaming compilers is speed. Comparing the WASMI interpreter with Lightbeam, we can see that it is about two orders of magnitude faster:

test native … Bench: 22,289 ns/iter (+/- 1,240) test wasmi… Bench: 3,602,303 ns/iter (+/ -41,855) test lightbeam… Bench: 22,266 ns/iter (+/- 1,242)

Note that Lightbeam seems to bea bit faster than native compilers, and Jack’s assumption is that they introduce an additional IR (i.e., Lightbeam IR) that allows for more optimization. Using standard Wasm compilation, the pipeline is as follows:

The Rust – MIR – – Wasm – Native LLVM IR

With Lightbeam, pipes have additional steps:

The Rust – MIR – the LLVM IR – Wasm – – Native Lightbeam IR

Lightbeam IR is a very simplified Wasm. Basically, Lightbeam removes local variables and layered control flows from Wasm.

Current focus: The beam seems to be passing all the tests, but that doesn’t mean it works. Performance improvements are possible. Fuzz testing is required for false compilations and bombs. Added support for 32-bit x86 and ARM64. You need to actually stream it because it is currently using some placeholders and tracebacks.

Excellent Runtime (OS)

Martin Becze

Martin’s speech was a call to action to start building an operating system that all blockchains can support and all smart contracts can run.

Martin first cautioned that one of the promises of blockchain is portability, which is not yet available because blockchain contracts cannot be ported across the entire blockchain, mainly because we don’t have standard interfaces and tools. EWasm is the first to address this problem by standardizing interfaces and metrics.

Unfortunately, eWasm is not designed to be portable because they do not treat it as an operating system. However, any blockchain with a smart contract can implement an operating system. Blockchains can then be thought of as similar to PC manufacturers — adapting to the OS layer. Such an OS layer should exercise POLA (minimum permissions) and not use environment permissions, which, by the way, is not the way * NIx or Ethereum currently works.

In general, operating systems need performance, security, portability, and tool-chain compatibility. However, blockchain operating systems also require deterministic and integrity checks on the file system, which are currently typically done through Merklization. Having a Merklized file system can actually be advantageous when running such an OS locally rather than on a blockchain. If so, SMART can run on local computers and blockchains.

Conversely, it would be nice if smart contracts had access to A POSIX-like API. It would be great if we could map a smart contract file system to a Linux file system without virtualization. This brings us back to WASI and POSIX discussed in other conversations.

Martin then began a discussion with the audience, who suggested that we could build adapters for POSIX at this point, but that we should not limit the development of alternative standards that are not affected by POSIX’s legacy. Martin agrees. The audience also noticed that trying to run apps locally, in the cloud, and on the blockchain might go beyond expectations, because we still can’t run the same apps on the phone and in the cloud, which is the first problem we need to solve.

Current focus: Martin’s speech was a call to action to start building the interfaces, kernels, and tools that will eventually lead to OS.

Evolve Wasm into appropriate misuse

Andreas Rossberg @ Dfinity

Andreas talked about future Wasm functionality and formalization aspects.

When developing new features, Wasm tries to strike a balance between performance, simplicity, versatility, and security by formalizing the entire Wasm for security and machine validation with Isabelle, Coq, and K. Wasm is easy to formalize, and its formalization is about 2 pages long, compared with 160 pages for the JVM. Interestingly, the JVM is not optimized for generality because it looks like a language built for it, whereas Wasm was not designed for any particular language.

Andreas then talks about Wasm’s much anticipated future features:

Multiple values allow instructions and functions to have multiple results, for example, by dividing the remainder. The multi-value implementation is basically to remove existing limitations from the Wasm form; Tail calls are also highly anticipated and will be enabled with special instructions. Batch instructions will allow efficient manipulation of data areas, similar to memcopy. Their implementation will need to reference functionality. References were originally part of the GC proposal, but have since been separated so that they can be shipped faster than GC. The motivation is simple: there is currently no easy way to pass a DOM object to Wasm and store a reference to it. Reference provides easy, efficient and secure interoperation with the host environment; They will also lay the foundation for future features such as exceptions and GC. Wasm needs to add two exception types: anyRef – general reference and its subtype funcref – special function reference. Interestingly, this is also the first instance of Wasm neutron typing. References can only be provided by the host, and Wasm code can only store references and pass them back. Special circumstances. Interestingly, today, if you compile C ++ to Wasm, all try blocks will become JS calls, which is slow and too specific. For C ++ projects, this is actually not a problem, as most of them do not use exceptions. Various control abstractions from other languages (such as coroutines, continuations, lightweight threads, asynchronous/wait, etc.) require stack switching. Garbage collection. Reimplementing GC in many languages is silly. Using GC in Wasm solves this problem, but also allows for better interoperation with the host. However, it will be limited to low-level data models, such as light structures and arrays, rather than mature objects. Unfortunately, while it simplifies some things, it also incurs a little overhead when used.

Current focus: In addition to the functionality described above, Wasm also wants to standardize subsets of the Wasm language, because not everyone needs every functionality, for example, blockchains don’t need threads.

K framework Wasm semantics

Rikard Hjort @ RuntimeVerification.com

Rikard holds hands-on workshops on using the K-framework.

The K framework allows for a working formal programming language specification. Once you have a formal specification of the language, you can generate things like parsers, interpreters, model checkers, compilers, and test cases. They already provide parsers, interpreters, debuggers, and reachability logic proffers for Java, C11, KVM, LLVM, and other real-world languages. Still in the works are Solidity and Rust. The project is very focused on blockchain and already has a formal specification of EVM on K, KEVM, with a repository of formally validated smart contracts, see: HTTPS: //github.com/runtimeverification/verified-smart-contracts

Wasm’s fast, deterministic, and verifiable calculations

Mike Voronov@ Fluence

Mike talked about the Fluence Blockchain, which uses a variety of consensus that relies on a verification game similar to Truebit. When there is a dispute over a particular state that a node does not agree on, the verification game Narrows the difference down to a single Wasm instruction, and then resolves the dispute on Ethereum by rerunning the disputed instruction.

They use k-ARY search for state tracking to find divergent instructions. In order to execute instructions on Ethereum, they need to send memory proofs, stacks, instruction Pointers, instruction counters to execute, and compressed gas via hashing and merging. However, because of their size, Merkization of memory is tricky, so they can only be Merklize memory “dirty” blocks, that is, modified blocks. This, in turn, requires charging users per dirty block to avoid a malicious attack that smudges the entire memory. Unfortunately, they do not currently support import from host, but portions of WASI will be allowed in the future.

Spacemesh smart Contract research

Yaron Wittenstein @ Spacemesh

Yaron showed Pomesh, which uses “grid” instead of blockchain, and Spacemesh, which uses PoST instead of PoW/PoS. Spacemesh is considering three options for smart contract languages: Solidity (running EVM on Wasm), eDSL on Rust and their own language, SMESH. SMESH will be secure in design, use advance computing where possible, and target Wasm. They will use WASMTime and Wasmer + Cranelift to run Wasm contracts.

About Patract

Patract provides solutions for parallel chain and DApp development in boca’s Wasm contract ecosystem. We help the community design and develop on-chain contract module and Runtime support, and provide DApp developers with a full stack of tools and services covering the development, testing, debugging, deployment, monitoring, data provisioning, and front-end development phases.

How to join Patract

1. For contract developers, visit the official website (Patract.io) to familiarize yourself with the test chain and tool suite. Element (app.element. IO /#/room/#Pat… Discord (Discord. Gg/wJ8TnTfjcq)

2. Welcome to Patract open platform: open.patract.io for parallel chain projects that will integrate the functionality of the Wasm contract, or DApp projects developed using the Wasm contract

3. For users, welcome to join: Telegram (t.me/ Patract) Twitter (twitter.com/PatractLabs…

4. For job seekers, we are recruiting blockchain development engineer, front-end/full stack development engineer, product manager, developer operation and other positions, you can contact [email protected]