Critique of @CosmWasm (small ๐งต)
CosmWasm is great:
- makes WASM work alongside Cosmos Msgs framework
- "secure-by-design," or better phrased "designed with security in mind" (actor model)
- Rust+WASM (can use crates)
However there are some problems which should be addressed:
CosmWasm is great:
- makes WASM work alongside Cosmos Msgs framework
- "secure-by-design," or better phrased "designed with security in mind" (actor model)
- Rust+WASM (can use crates)
However there are some problems which should be addressed:
1/ DIFFICULTY
Not just hard to get started, but hard to write simple things:
- ops like new state have many changes in multiple files
- Rust = noisy medium w/ weird syntax
Ironically, it makes the hard things easy (like complex math impls w/ crates) but the easy things hard.
Not just hard to get started, but hard to write simple things:
- ops like new state have many changes in multiple files
- Rust = noisy medium w/ weird syntax
Ironically, it makes the hard things easy (like complex math impls w/ crates) but the easy things hard.
2/ COMPLEXITY
Complexity thus grows exponentially with this formula:
complexity = tasks^2 * difficulty / (composeability)
Large dApp projects spread out across many contracts become increasingly difficult to read.
Complexity thus grows exponentially with this formula:
complexity = tasks^2 * difficulty / (composeability)
Large dApp projects spread out across many contracts become increasingly difficult to read.
3/ VARIATION
To &mut or not to &mut, that is the question.
Too many degrees-of-freedom result in inconsistency.
- project structure
- build script
- code style
- options, types, weird ad-hoc traits
To &mut or not to &mut, that is the question.
Too many degrees-of-freedom result in inconsistency.
- project structure
- build script
- code style
- options, types, weird ad-hoc traits
4/ AUDITABILITY
Solidity contracts may be vulnerable but at least they're easily auditable.
CW contracts are performant but written like programs for computers, not contracts for humans.
Ironically this makes them less secure than Solidity contracts cuz fewer eyes reading them
Solidity contracts may be vulnerable but at least they're easily auditable.
CW contracts are performant but written like programs for computers, not contracts for humans.
Ironically this makes them less secure than Solidity contracts cuz fewer eyes reading them
4/ (addendum)
We haven't had a source code viewer yet for CosmWasm like you'd find with @etherscan because the build system has too many points where they can vary.
We haven't had a source code viewer yet for CosmWasm like you'd find with @etherscan because the build system has too many points where they can vary.
5/ LACK OF GUIDANCE
Due to a lack of clear guidance from @confio_tech (probably busy with other stuff) the community is conflicted over which patterns should be adopted.
This is a contributing factor to variance.
Due to a lack of clear guidance from @confio_tech (probably busy with other stuff) the community is conflicted over which patterns should be adopted.
This is a contributing factor to variance.
6/ COMPOSABILITYโ (see note)
Though technically able through adoption of Rust's system of crates, there isn't yet a clean manner to compose like with classes.
Instead you're given many options on how to integrate features, many just copy code from @mirror_protocol.
Though technically able through adoption of Rust's system of crates, there isn't yet a clean manner to compose like with classes.
Instead you're given many options on how to integrate features, many just copy code from @mirror_protocol.
7/ LACK OF MANIFEST / ABI
Ethereum ABI is a canonical representation of a contract's interface against which it can be checked.
CW's de-facto ABI JSON Schema but needs to be more complete and unified (describe all parts of contracts), shippable in a single file.
Ethereum ABI is a canonical representation of a contract's interface against which it can be checked.
CW's de-facto ABI JSON Schema but needs to be more complete and unified (describe all parts of contracts), shippable in a single file.
8/ HARD TO DEBUG
@CosmWasm has made it difficult to debug, providing only 1 print instruction.
To read it, you need a node. We need more.
I had to fork the @terra_money node and add my own debug instructions for tracing and other metrics (gave assignment to screen @octalmage).
@CosmWasm has made it difficult to debug, providing only 1 print instruction.
To read it, you need a node. We need more.
I had to fork the @terra_money node and add my own debug instructions for tracing and other metrics (gave assignment to screen @octalmage).
9/ SMART CONTRACT VERIFICATION
It's hard to know whether or not a smart contract's uploaded WASM binary, which has been stripped of all meaningful symbols and obfuscated by it's optimization.
Proud to announce a partnership between @realTerranOne & @TerraSCV led by @unl1k3ly
It's hard to know whether or not a smart contract's uploaded WASM binary, which has been stripped of all meaningful symbols and obfuscated by it's optimization.
Proud to announce a partnership between @realTerranOne & @TerraSCV led by @unl1k3ly
10/ THE SOLUTION
@realTerranOne we're aiming to build tools for @terra_money builders, but dealing with all this means we can only work on tooling that caters to the most common denominator.
Most of these problems can be solved through just a set of standards.
@realTerranOne we're aiming to build tools for @terra_money builders, but dealing with all this means we can only work on tooling that caters to the most common denominator.
Most of these problems can be solved through just a set of standards.
11/ SM Framework
Our first project is the Standard Model -- an elegant framework of elementary standards and fundamental guidelines for smart contracts.
This gives us basic guarantees for better tools.
We are actively developing it currently, DM me if you want to help out!
Our first project is the Standard Model -- an elegant framework of elementary standards and fundamental guidelines for smart contracts.
This gives us basic guarantees for better tools.
We are actively developing it currently, DM me if you want to help out!
12/ CWScript
CWScript started out as simple notation for contracts -- designed to make reading and communication between non-devs easier.
We will be publishing a usable version which will generate SM-compliant patterns of CW Rust.
CW20 translation: github.com
CWScript started out as simple notation for contracts -- designed to make reading and communication between non-devs easier.
We will be publishing a usable version which will generate SM-compliant patterns of CW Rust.
CW20 translation: github.com
13/ LANG TOOLING
With language tooling, we get the potential for:
- auto doc gen
- library / SDK gen
- SM linting
- auto-inserted debug traces
- editors
Big shout-out to @strumenta for helping out in CWScript!
Check out their blog for awesome dev resources.
With language tooling, we get the potential for:
- auto doc gen
- library / SDK gen
- SM linting
- auto-inserted debug traces
- editors
Big shout-out to @strumenta for helping out in CWScript!
Check out their blog for awesome dev resources.
Loading suggestions...