✔️Smart Contracts

Overview

Glitch provides two smart contract virtual machines which can be added to Glitch’s runtime. Each comes with additional tools to ease development.

2 types of virtual machines:

  • Contract pallet: execute WebAssembly Smart Contracts

  • EVM pallet: provides an EVM execution environment for Glitch's Ethereum compatibility layer. It allows unmodified EVM code to be executed in a Glitch-based blockchain, designed to closely emulate the functionality of executing contracts on the Ethereum mainnet within the Glitch runtime.

Description

Since smart contract logic can be published by anyone, including malicious actors and inexperienced developers, there are a number of intentional safeguards built around these public smart contract platforms. Some examples are:

  • Fees: Ensuring that contract developers are charged for the computation and storage they force on the computers running their contract, and not allowed to abuse the block creators.

  • Sandbox: A contract is not able to modify core blockchain storage or the storage of other contracts directly. Its power is limited to only modifying its own state, and the ability to make outside calls to other contracts or runtime functions.

  • State Rent: A contract takes up space on the blockchain, and thus should be charged for simply existing. This ensures that people don't take advantage of "free, unlimited storage".

  • Reversion: A contract can be prone to situations that lead to logical errors. The expectations of a contract developer are low, so extra overhead is added to support reverting transactions when they fail so no state is updated when things go wrong.

These different overheads make running contracts slower and more costly. Contracts allow your community to extend and develop on top of your runtime logic without needing to go through all the processes like proposals, runtime upgrades, etc...

In summary, Glitch Smart Contracts:

  • Are inherently safer for the network.

  • Have built-in economic incentives against abuse.

  • Have computational overhead to support graceful failures in logic.

  • Have a lower bar to entry for development.

  • Enable fast pace community interaction through a playground to write new logic.

Last updated