diff --git a/teamupdates/update-43-2021.md b/teamupdates/update-43-2021.md new file mode 100644 index 0000000000..3ea867f8c9 --- /dev/null +++ b/teamupdates/update-43-2021.md @@ -0,0 +1,22 @@ +# Smart Contract Team Updates - Week 43, 2021 + +- Last week the Beta version of IOTA Smart Contracts was released. The Smart Contract team has been busy with this throughout last week with last minute fixes, improved documentation, monitoring the usage after release and identifying and fixing any reported issues after the release. Several small issues have been identified and are either resolved already or being worked on right now. In addition to this additional logging has been implemented to make debugging issues with smart contracts a bit easier. We'll release version 0.2.1 this week to address the issues that have been resolved. After this release we'll merge in some bigger pull requests like a first version of EVM-Light (a more lightweight alternative to the stock EVM) and the improved Channels/Pipes implementation. + +- We are currently working on defining the details of the next release of IOTA Smart Contracts. The main focus of this release will be support for the new output types (specifications will follow soon) and Chrysalis support, replacing the current GoShimmer compatibility with Hornet compatibility. Improved EVM support with the option to use tokenized assets from outside EVM is a target as well. + +- From a research perspective we also worked on simulations for more performant gossip between committee nodes with the aim to improve the performance here and we continued the effort to investigate potential dynamic committee rotation. + +- EVM-Light is ready to be merged as a first version, which allows us to test this implementation in real world scenario's with existing Solidity contracts. +EVM Light is an in-house alternative to EVM which can be run instead of the original EVM, utilizing a large part of the existing EVM Core but with further optimizations for usage with IOTA Smart Contracts. EVM Light supports the same Solidity contracts, but is much more efficient when it comes to state storage, reducing storage requirements and increasing performance of EVM-based smart contract execution. This alternative to EVM is also easier to modify allowing us to implement additional IOTA Smart Contract functionality directly into EVM, such as utilizing the random number generator in IOTA Smart Contracts, or interacting with the IOTA Tangle directly. +Our current EVM blocks don't have a predictable block interval which is sometimes used by Solidity smart contracts to calculate a crude perception of time. We are currently looking into supporting more predictable block intervals for EVM to support these use-cases as well. + +- We are working on a whitepaper version of IOTA Smart Contracts next to the Architecture document we already have. This document is currently being drafted and peer-reviewed by various team-members. + +- For the WASM based smart contracts we are looking at support for AssemblyScript (a TypeScript variation) next to our existing TinyGo and Rust implementations. A big effort has been made here already and we should be able to add this option as well in a future release. +In addition we will be looking at replacing our current Wasmtime implementation with Wasmer and implementing gas metering for WASM based smart contracts. We'll also improve the documentation for the WASM based smart contracts adding additional clarity about the usage of the Schema tool based on user feedback after release. + +- Wasp node metrics support using Grafana/Promotheus has been added to Wasp and new metrics are being added on request. There's quite a backlog of these so this will be a ongoing project. Documentation for these metrics has been added and will be merged soon. + +- Last week we launched the IOTA Smart Contracts testnet, which is currently being improved with additional metrics and logging. We will release a new version of the testnet soon containing the latest improvements we added after last week's release. + +- Finally, in parallel to all this work, we are also wrapping up the RFC specifications for the new tokenization framework which adds SC support to Chrysalis. This is currently being reviewed internally before being released publicly.