mleku/warp
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: readme and tsdocs updated

Browse Source
This commit is contained in:
ppedziwiatr
2021-09-17 15:05:38 +02:00
committed by Piotr Pędziwiatr
parent df52478bd9
commit a6596f7244
12 changed files with 205 additions and 117 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
docs/CONTRACT_METHODS.md
View File

@@ -5,7 +5,6 @@
- [`setEvaluationOptions`](#setevaluationoptions)
- [`readState`](#readstate)
- [`viewState`](#viewstate)
- [`viewStateForTx`](#viewstatefortx)
- [`writeInteraction`](#writeinteraction)
## Contract Methods

2
docs/MIGRATION_GUIDE.md
View File

@@ -1,4 +1,4 @@
# Migration Guide from SmartWeave v1 to SmartWeave v2
# Migration Guide from Arweave's SmartWeave SDL to RedStone SmartContracts
This guide describes <strong>the simplest</strong> way to switch to the new version of SmartWeave. It uses `SmartWeaveNodeFactory` for Node and `SmartWeaveWebFactory` for Web to quickly obtain fully configured, mem-cacheable SmartWeave instance. To see a more detailed explanation of all the core modules visit the [SmartWeave v2 documentation](https://smartweave.docs.redstone.finance/) or check out the [source code.](https://github.com/redstone-finance/redstone-smartweave)

54
docs/ROAD_MAP.md
View File

@@ -1,26 +1,25 @@
# SmartWeave v2
# RedStone SmartContracts SDK
### The issues with the current implementation
### 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... :-(((
* 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 (ie. adding cache) basically requires to make a c/p of the base function
* 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 hard to keep the copy-pasted version up to date with base implementation
* sometimes a bit "chaotic" implementation (ie. not sticking to one naming convention, multiple optional function arguments, etc.)
- 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 "v2" approach
1. Clearly defined core protocol layers/interfaces/tags, etc.
All of this is kept in the "core" directory.
### The "RedStone SmartContracts" approach
1. Clearly defined core protocol layers/interfaces/tags.
2. OOP implementation
3. Each of the base protocol interface can be easily and independently tested
4. Keep the "core" layer at the bare minimum
5. All additional features (like "evolve" feature or caching or "dry-runs") should build on top of the core layer ("plugins" directory)
4. The "core" layer should be kept at a bare minimum - to reduce the risk of mistakes in core protocol implementation.
5. All additional features (like "evolve" feature or caching or "dry-runs") should build on top of the core layer ("plugins")
6. Option to easily substitute different implementations of the core layers (ie. with or without caching, different ExecutorFactories, etc.)
7. proper use of types in Typescript
8. strongly typed state and handler's api (generics)
8. strongly typed state and handler's api (i.e. generics)
### Roadmap
@@ -29,23 +28,28 @@ All of this is kept in the "core" directory.
2. Description of the core building blocks (in the source code) - done
3. Example caching capabilities implementation - done
4. Example "evolve" implementation - done (my concerns re. this feature described in Evolve.ts and in [this analysis](EVOLVE_analysis.md)))
5. Example usage with one of RedStone's contracts - done (call `yarn run v2`)
5. Example usage with one of RedStone's contracts - done
6. new readContract and interactWrite implementations - done
7. updating the SmartWeaveGlobal definition (with updated readContract version) - done
8. Kyve cache implementation (probably with collaboration with Kyve team) - TODO
9. Verifying output results for X currently "most popular" (with most interactions?) contracts - done for all contracts
10. unit tests for all the core layers and plugins/caches (because screw TDD...;-)) - TODO
11. even more unit tests - TODO
12. did I mention unit tests? TODO
13. release as a separate npm library?
7. release as a separate npm library - done
8. updating the SmartWeaveGlobal definition (with updated readContract version) - done
9. Adding ability to call "interactRead" from the contract's source code. - done
10. Kyve cache implementation (probably with collaboration with Kyve team) - done
11. Verifying output results for X currently "most popular" (with most interactions?) contracts - done for all contracts
12. regression tests - done
13. integration tests - done
14. documentation, migration guide, usage examples for node and web env., tutorial - done
15. unit tests for all the core layers and plugins/caches - in progress
#### Phase 2 - TODO
1. Contract's source code versioning (using standard semantic versioning) - sth. similar to "pragma solidity ^0.8.2;"
2. Adding ability to call "interactRead" from the contract's source code.
1. Contract's execution environment isolation
2. Generating a stack trace from all the contract interactions
#### Phase 3 - TODO
1. Contract's execution environment isolation
1. Contract's source code versioning (using standard semantic versioning) - sth. similar to "pragma solidity ^0.8.2;"
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
1. 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);
Thing on top of the SDK eg:
1. Custom Gateway, optimized for interactions with SmartWeave contracts
2. Custom Viewblock-like contracts explorer