3.3 KiB
3.3 KiB
RedStone SmartContracts SDK
The issues with original smartweave.js SDK
- low performance (unnecessary calls to Arweave http api, no easy option to add caching layer, etc.)
- no clearly defined base protocol
- implementation that is really hard (if not impossible...) to unit test
- no tests, very prone to errors (eg. recent issue with input tags format)
- many c/p in the code (like the recent "evolve" feature)
- any change in the base function (i.e. adding cache) basically requires to make a c/p of the base function
and add required changes (eg. Kyve's own version of readContract/interactRead functions)
- this of course makes it really to maintain and keep the code up to date with base implementation
- sometimes a bit "chaotic" implementation (i.e. not sticking to one naming convention, multiple optional function arguments, etc.)
The "RedStone SmartContracts" approach
- Clearly defined core protocol layers/interfaces/tags.
- OOP implementation
- Each of the base protocol interface can be easily and independently tested
- The "core" layer should be kept at a bare minimum - to reduce the risk of mistakes in core protocol implementation.
- All additional features (like "evolve" feature or caching or "dry-runs") should build on top of the core layer ("plugins")
- Option to easily substitute different implementations of the core layers (ie. with or without caching, different ExecutorFactories, etc.)
- proper use of types in Typescript
- strongly typed state and handler's api (i.e. generics)
Roadmap
Phase 1 - in progress
- Base protocol definition and implementation of the core/protocol layers - done
- Description of the core building blocks (in the source code) - done
- Example caching capabilities implementation - done
- Example "evolve" implementation - done (my concerns re. this feature described in Evolve.ts and in this analysis))
- Example usage with one of RedStone's contracts - done
- new readContract and interactWrite implementations - done
- release as a separate npm library - done
- updating the SmartWeaveGlobal definition (with updated readContract version) - done
- Adding ability to call "interactRead" from the contract's source code. - done
- Kyve cache implementation (probably with collaboration with Kyve team) - done
- Verifying output results for X currently "most popular" (with most interactions?) contracts - done for all contracts
- regression tests - done
- integration tests - done
- documentation, migration guide, usage examples for node and web env., tutorial - done
- unit tests for all the core layers and plugins/caches - in progress
Phase 2 - TODO
- Contract's execution environment isolation
- Generating a stack trace from all the contract interactions
Phase 3 - TODO
- Contract's source code versioning (using standard semantic versioning) - sth. similar to "pragma solidity ^0.8.2;"
- Alternation ExecutorFactory implementations - the one that would allow create handlers for contract's written in a more OOP approach (so instead one "big" handle function, contract can define its interface and class-based implementation);
Phase 4 - TODO
Thing on top of the SDK eg:
- Custom Gateway, optimized for interactions with SmartWeave contracts
- Custom Viewblock-like contracts explorer