Overview | ink! documentation

Openbrush

• testing

  • on-chain mode: no_std + WebAssembly as target
  • off-chain mode: std
  • #[ink::test] will simulate on-chain mode

• storage

  • All the fields of the #[ink(storage)]struct will be pulled from storage, regardless of whether or not they are used during the message execution.

  #[ink(storage)]
  pub struct EagerLoading {
      a: i32,
      b: ink_prelude::vec::Vec<i32>, // may be large
  }
  
  impl EagerLoading {
      #[ink(message)]
      pub fn read_a(&self) {
  				// b will be loaded as well
          let a = self.a; 
      }
  }
  

• Prevent using Rust stdlib collections, since they are not optimized for smart contract usage

  • Just think about a Vecor a HashMapwhere the smart contract might only need access to a few elements, rather than the entire data collection.

Solidity VS ink!

ink! vs. Solidity | ink! documentation

• no uint256
  • u128 is the largest
  • [u64; 4]
• mapping: more complicated
  • initialize
    • An implementation of the SpreadAllocate trait on our storage struct
    • The ink_lang::utils::initalize_contract initializer
  • nested: BTreeMap + PackedAllocate
• cross-contract calling: more complicated
  • Instantiate the cross-called-contract in the main contract's constructor.
  • add the AccountIdof an already deployed contract.
• Current limitations of ink! v3
  • Multi-file projects are not supported with pure ink!
    • implementing traits / interfaces will not work
    • There are alternatives that do add this functionality such as OpenBrush
  • Nested structs and data structures can be difficult to use
  • Cross-contract calling prevents events from being emitted. See here for details.
  • Cross-contract calling can not be tested offchain with unit tests. On-chain integration tests will need to be used.

EVM vs WASM Smart Contracts

• https://docs.openbrush.io/evm-wasm-smart-contracts
• Common point: they both are a sandbox to execute smart contracts
• WASM is more broadly adopted
• EVM bytecode can only be compiled from Solidity or Vyper, while WASM can be compiled from a lot of Popular languages (Rust, C/C++, C#, Java, Typescript, Haxe, Kotlin and even from Solidity)
• The engine which executes contracts is different.

  • EVM is rather limited and slow

  • Contract pallet integrates a  Two Step Deployment to decouple contract code and contract instances

  • Two Step Deployment:

  • Deploying a contract with the Contracts module takes two steps:

    1. Store the Wasm contract on the blockchain.
    2. Instantiate a new account, with new storage, associated with that Wasm contract.

    This means that multiple contract instances, with different constructor arguments, can be initialized using the same Wasm code, reducing the amount of storage space needed by the Contracts module on your blockchain.

FAQ

• #![cfg_attr(not(feature = "std"), no_std)] ?

  • conditional compilation

  if feature != "std":
  	enable no_std -> WASM on-chain mode
  else:
  	std is enabled -> off-chain mode