Grug is an execution environment for blockchains. It's an alternative to the EVM, Solana VM, Move, and CosmWasm.
Grug is much faster than single-threaded EVM, but probably not as fast as SVM or Move (they are the results of multiple years of grinding by extremely well-funded teams; we can't compete with that).
Instead, Grug differentiates itself by its rich features. The idea is that there're many apps that are difficult to build in EVM, SVM, Move, etc. because those VMs lack certain features that these apps need, but they will be easy to build with Grug. Such features include:
While it took Ethereum almost 4 years to ship EIP-3074, Grug comes packaged with a complete smart account solution from the get go.
This solution builds on our previous work of the very first smart account solution in Cosmos, which is used by Xion to onboard 100k users, processing 1100 TPS without any hiccup.
Our solution allows one to program smart contract accounts that authenticate transactions with arbitrary logics as the developer likes. This can include Passkey, one-time password, two-factor authentication, and so on.
We believe the endgame wallet experience is a key-less one. The user will, for example, generate and store a private key in their iCloud so that it's accessible from any device, and sign transactions with fingerprint and Face ID. Our smart account solution enables this.
Another use case uniquely enabled by our smart account solution is a new DeFi primitive called credit account. It allows users to take uncollateralized[1] margin loans, something not possible with traiditonal lending protocols such as Compound and Aave. Credit accounts are also cross-margin, meaning one can take on multiple activities within the account: spot trading, futures trading, yield farming... which will collateralize each other (capital efficient).
Credit account is possible thanks to two innovations: 1) the account will backrun each transaction, rejecting it if the actions result in the health factor dropping below a threshold; and 2) a liquidation mecanism is built into the account. While it's not impossible to implement these in traditional VMs (see similar works by Mars and Gearbox protocols), they tend to suffer from high complexity (a lot of workarounds are necessary due to lack of a smart account system), poor user experience (e.g. credit accounts are not "real" accounts hence won't show up in wallet apps), and high gas cost. Grug can easily reduce the codebase size by 80%, be much cheaper, and offer good UX.
A guideline we employ in designing Grug is that if we expect developers may want to customize something, then this thing should be abstracted into a smart contract; if it's something that we don't expect any developer to ever want to customize, then it will be native Rust code. With this, developers never have to fork chain-level code to achieve their objectives. All they need to do is to write contracts.
This is in contrary to the EVM, in that, for example, if you don't like the floating gas price in EIP-1559 and want a flat price instead, you will have to fork and change the core Ethereum protocol. This is risky and beyond the capability of most developers.
In Grug, gas fees are managed by a smart contract, nicknamed the taxman. After each transaction, taxman is invoked and provided with a report of the transaction and its gas consumption. Developers can implement any logic to handle the fee, for example:
Additionally, if at any time the community wishes to change the fee mechanism, they don't have to harkfork the chain. All that's necessary is to migrate the contract.
Another interesting use case is that since taxman backruns every transaction, it's possible to use it to capture protocol-owned MEV, similar to Osmosis' ProtoRev module.
A big issue for DeFi chains is spamming; that is, the situation where the network becomes congested (either because of organic user activities or of an attack) and some crucial transactions (such as updating oracle prices or liquidations) can't get in, which can result in bad debts.
A solution to this is to create a "separate lane" - a special section in blocks, separate from regular transactions, just for these crucial operations. Fortunately, this is provided to us by Tendermint's ABCI++ through a mechanism called vote extension.
Several Cosmos chains, including dYdX, already utilize vote extension to submit oracle data using Skip Protocol's Slinky plugin.
With Grug, smart contracts will have access to vote extension, and we plan to ship an oracle system similar to Slinky.
A cronjob is an operation that needs to be performed at regular time intervals. For instances,
In EVM, developers need to rely on bots to carry out these, since actions can only be triggered by submitting transactions. Relying on offline infrastrucutre such as a bot network increases operating cost and are susceptible to network congestions as discussed in the previous section.
The Cosmos SDK pioneered a solution to this known as the Begin/EndBlocker. Essentially, developers can create actions to be performed automatically at the beginning or the end of each block, without manual invocation. Since these actions are not triggered by transactions, they do not suffer from congestions.
In Grug, we borrow the idea of Begin/EndBlockers, giving smart contracts access to them.
ERC-20 is a terrible token standard. It's bad for users, bad for developers, bad for indexers. Literally no one likes it, but Ethereum is stuck with it for eternity since numerous DeFi apps already depend on it.
A few reasons why ERC-20 is so bad:
transferAndCall and is available on several other token standards such as ERC-677, but they are not widely adopted; even if they are, you can still only transfer one token at a time, so for use cases where it's necessary to transfer two or more tokens then call the contract (e.g. providing liquidity to an AMM) this doesn't work.
approval mechanism was invented. This however created massive security risks. Many apps have users make infinite approvals in order to save on gas, but this also means in case the app is exploited, users' funds can be infinitely stolen.
receive function, in which the contract can reject transfers, but it only works for ETH, not ETH-20s.
Grug's native token standard fixes all these issues except for the last one (we can do it, but doing so increases state size a lot and as far as I'm concerned, isn't worth it). Furthermore, it unifies fungible tokens and NFTs under a single standard, borrowing ideas from Osmosis and Metaplex.
IBC is the best interoperability protocol (if you disagree, you're wrong). Grug enshrines IBC natively as part of the VM.
On the business side, having IBC allows us to easily onboard USDC holders from any ecosystem though Circle's CCTP and Noble.
mapping data structure. The lack of this capability means developers often have to implement complex workarounds just to create simple functionalities. In Grug, iteration is natively supported thanks to our innovative approach of handling chain state.
null type. That is, if a contract says a number is zero, it's impossible to tell whether this number is indeed zero, or that it's simply uninitiated. This ambiguity is a huge security pitfall. Grug supports null type (or rather, Rust supports null type and Grug just gets it for free).
We explicitly make the choice to NOT invent a new language, in contrary to what some of our competitors do (Solidity, Move, Fuel). Inventing a new language means you have to reinvent all the tooling, rewrite and re-audit all the libraries; not worth it.
Furthermore, your compiler probably won't be very good. A compiler is a tremendously complex piece of software; a domain-specific language, with its limited user base, is unlikely to have the resource to spend on perfecting it. This is why we often see Solidity devs resorting to writing assembly code - the compiler simply isn't capable of producing gas-efficient bytecodes.
Grug smart contracts are written in Rust, the most admired programming language 8 years in a row, and compile to WebAssembly (Wasm).
While calling contracts, Grug uses Wasmer, a highly optimized Wasm runtime that utilizes a just-in-time (JIT) compiler to achieve near native performance, which can be 10-100x cheaper in computation and up to 100-500x cheaper in memory usage compared to single-threaded EVM, according to benchmarks done by Arbitrum, which also uses Wasmer for its Stylus framework.
Wasm is also supported by all modern web browsers. This opens up new possibilities for frontend develpement (check out this presentation).
Another cool thing about using Rust/Wasm is that it often gets better without us having to do anything. For instance, the Rust 1.63 release reduces compiled contract sizes by up to 40%. We enjoy the contributions from numerous Rust/Wasm users outside of the crypto space, a luxury that domain-specific languages don't have.
To create a fully functioning blockchain, Grug needs to be coupled with a sequencing layer. If you couple it with a layer-1 consensus protocol, you get an L1 chain; couple it with a layer-2 sequencer, you get an L2 chain.
Grug talks with the sequencing layer through the Application-Blockchain Interface (ABCI). Any ABCI-compatible sequcing solution should work, such as:
Grug V1 won't come with verifiable computation; our team set this aside for now and focus on shipping some apps first. Eventually though, we plan to make Grug ZK-provable utilizing one of the zkVMs: RiscZero, SP1, Jolt, Fluent, or zkLLVM.
Besides these, we will also investigate state eviction, which is a solution to state bloating, believed to be the greatest obstacle for Ethereum scaling. Our solution will be similar to what is proposed in the Diem whitepaper (§4.4).
We will also investigate parallel transaction processing using Block-STM.
Grug is heavily inspired by CosmWasm, both in architecture design and in borrowing actual code (in compliance with the Apache-2.0 license). It's safe to say that Grug simply won't exist without the pioneering work by CosmWasm. Our big thanks to the CosmWasm creators.