From 1a2d2457aae113947f8a6ffc514a2539001e3bdc Mon Sep 17 00:00:00 2001 From: Aria Thaker <51683211+ariathaker@users.noreply.github.com> Date: Thu, 18 Jul 2024 17:19:46 -0400 Subject: [PATCH] Update gnovm-evm-cosmwasm.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Resolve all of @zivkovicmilos' edits except one (see bullet #5). Major revisions include: 1. Elaborate on state persistence, especially in the EVM. Include an example of a voting contract 2. Add specifics re: tooling that Solidity smart contract developers must learn 3. Describe how the GnoVM's design restricts memory access for security purposes 4. Elaborate on Go and the principle of least privilege 5. Change not added yet: new section to replace the last one on blockchain source code. I've posted a few clarifying questions in response to Miloš' comment. --- docs/concepts/gnovm-evm-cosmwasm.md | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/docs/concepts/gnovm-evm-cosmwasm.md b/docs/concepts/gnovm-evm-cosmwasm.md index 8a833f7d9f0..2b26bd5c507 100644 --- a/docs/concepts/gnovm-evm-cosmwasm.md +++ b/docs/concepts/gnovm-evm-cosmwasm.md @@ -19,23 +19,31 @@ See the image below for a side-by-side comparison of code written for all three The most obvious difference between the three programs is length, with the CosmWasm smart contract requiring substantially more characters than the other two put together. This is standard; the GnoVM and the EVM allow for much more succinct code than CosmWasm does. In CosmWasm, the same counter that the GnoVM and the EVM each handle in one short program is split into four files. While this modular approach may allow for composability, it makes for a challenging initiation for developers new to smart contracts. -Language choice is another key factor that influences the ease of onboarding. In this case, the GnoVM comes out comfortably ahead of both CosmWasm and the EVM. Rust is a notoriously difficult language, and the need for developers to use it, on top of familiarizing themselves with the actor-model rules about passing messages between components only steepens CosmWasm's learning curve. +Language choice is another key factor that influences the ease of onboarding. In this case, the GnoVM comes out comfortably ahead of both CosmWasm and the EVM. Rust is a verbose language with syntax and memory-management rules that many consider complex. The need for developers to learn Rust, on top of familiarizing themselves with the actor-model rules about passing messages between components, steepens CosmWasm's learning curve. -The EVM asks a lot of new developers as well. While Solidity may not be as syntactically complex as Rust, it is not a widely used or general-purpose language, nor is it the sole language used in EVM-compatible tech stacks. This means developers looking to use Solidity must not only learn a completely new language, but also either learn or brush up on several others—often JavaScript, Rust, and Go. +The EVM asks a lot of new developers as well. While Solidity may not be as syntactically complex as Rust, it is not a widely used or general-purpose language, nor is it the sole language used in EVM-compatible tech stacks. This means developers looking to use Solidity must not only learn a completely new language, but also may need to learn other tools that are based on different languages. For example, they may need to learn Javascript-based environments for Solidity smart contract development such as Hardhat or Truffle, or libraries such as the Python-based web3.py or the Javascript-based Web3.js or Ether.js. -Meanwhile, the GnoVM operates entirely on Gno, which is [99% identical to Go](https://gno.land/r/gnoland/blog:p/intro), a complete and widely used programming language. Developers new to blockchain are much more likely to know Go than they are to know Solidity or Rust. The ability for developers to tap into the Go ecosystem and access type checking, garbage collection, and many of the standard libraries, among other features and tooling, makes Gno highly usable even compared to Rust—and certainly compared to a narrowly specialized language like Solidity. +Meanwhile, the GnoVM operates entirely on Gno, which is [nearly indistinguishable from Go](https://docs.gno.land/reference/go-gno-compatibility/), a concise, readable and widely used programming language. Developers new to blockchain are much more likely to know Go than they are to know Solidity or Rust. The ability for developers to tap into the Go ecosystem and access type checking, garbage collection, and many of the standard libraries, among other features and tooling, makes Gno highly usable even compared to Rust—and certainly compared to a narrowly specialized language like Solidity. ## State Persistence Boosts Efficiency Smart contracts on the GnoVM have state persistence, meaning they can be frozen and resumed and their memory will be automatically saved. This decreases the likelihood of programming errors and provides a smoother development experience. It also improves program succinctness, because programmers need not manually reference databases to store objects in memory. -CosmWasm's state management is made more complex by its use of actor-model message passing. This complexity places a higher burden on the developer, who needs to deal with manual state management across multiple files for a single contract. The EVM is not much better, also requiring developers to handle state explicitly using serialization. +CosmWasm's state management is made more complex by its use of actor-model message passing. This complexity places a higher burden on the developer, often requiring them to split even a simple smart contract into multiple files across which they must simultaneously manage state persistence. + +The EVM’s use of state persistence in smart contracts is more straightforward than CosmWasm’s, since it typically does not require developers to monitor and manage state across as many files. However, it still requires developers to be vigilant about the distinction between memory, which is transient between transactions, and storage, which is persistent. A developer mistakenly recording a variable into memory versus storage might result in confusion or error when the value is not recorded automatically. + +Consider the example of a voting smart contract. The Gno developer’s vote count variables are automatically persisted after each voting transaction, ensuring ongoing election updates. On CosmWasm, the developer must manually manage the state of variables across several different files. The EVM developer may also be able to leverage automatic persistence if the variables are recorded in storage, but if they are mistakenly recorded in memory, users may be caught off guard when the counts are reset after each vote. ## The Go Ecosystem Provides Security -The EVM is known to be [vulnerable to reentrancy attacks](https://docs.cosmwasm.com/docs/architecture/smart-contracts/), which occur when a function externally calls an untrusted contract. Both the GnoVM and CosmWasm offer robust protection against this type of attack. CosmWasm entirely prevents any contract from directly calling another contract, while the GnoVM's design restricts direct memory access and handles state management internally. +The EVM is known to be [vulnerable to reentrancy attacks](https://www.quicknode.com/guides/ethereum-development/smart-contracts/a-broad-overview-of-reentrancy-attacks-in-solidity-contracts), which occur when a function externally calls an untrusted contract. + +Both the GnoVM and CosmWasm offer robust protection against this type of attack. CosmWasm’s actor-model message passing prevents any contract from directly calling another contract, mitigating the risks of these types of attacks. The design of GnoVM also shields against reentrancy by managing state changes internally through a controlled process, as opposed to allowing direct external interactions that could interrupt the execution flow. GnoVM restricts direct memory access, meaning contracts cannot arbitrarily read from or write to the memory space of other contracts. These restrictions help in maintaining a clear boundary between contract states, preventing unauthorized access. + +The GnoVM also leverages the strong security principles of Go. The language's simplicity reduces the chance of programming errors. Many aspects of its design and syntax also make Go especially compatible with the principle of least privilege–for example, the ease of distinguishing between exported and non-exported fields using capitalization. The principle of least privilege minimizes attack surface and reduces the risk of vulnerabilities by dictating that each user or program should have only the permissions it needs to perform its function, and nothing more. -The GnoVM also leverages the strong security design of Go. The language's simplicity reduces the chance of programming errors, as does its reliance on the principle of least privilege. Gno developers can also tap into the robust third-party tooling of the Go ecosystem. For example, they can access tools for static analysis that would make it easier to design secure smart contracts. +Gno developers can also tap into the robust tooling of the Go ecosystem, accessing analysis tools that would make it easier to design secure smart contracts. Some of these include the vulnerability scanner [govulncheck](https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck), as well as the command [go vet](https://pkg.go.dev/cmd/vet), which examines source code and reports suspicious constructs. ## On-chain Readability Promotes Transparency