As a space, we talk a lot of game about decentralization. The core tenet of this principle value is that we shan’t need central actors in order to interact onchain. And that’s a really big claim worth investigating, especially since we love to shout into a megaphone about how much we value our decentralization. Yet, curiously we continue to fail in our efforts to persuade our blupilled brethrens in taking the redpill. So I am here to investigate a would-be casual user’s most common touchpoints onchain and pose the question (and hopefully answer):

“Just how decentralized is decentralized?”

So let’s olympic-dive into this mafaaaa and see “wha happuns” with the following hypothetical failures:

1. A web/hot wallet failure 👜
2. A hardware wallet failure 🔑
3. A failure in communicating with the chain (e.g. Infura endpoint goes down) 🗣
4. A dApp frontend failure 🖼
5. A block explorer failure ⛵️

Note: as a predominantly Ethereum-based actor, I shall talk about Ethereum. Unfortunately, I neither have the networth nor the time to get into other L1 ecosystems at depth.

A web/hot wallet failure, otherwise known as `wtf do we do if MetaMask breaks?`

If we are redpilling our friends about the magic of onchain, we typically start them off with — and let’s acapella this together please:

SELF-CUSTODYING YOUR ASSETS

Great, and I am glad we are all on the same page about the most important thing in crypto™. And since hardware wallets are typically a bigger product hurdle for casuals, we noble few evangelizers (praise be) might turn them onto a more common entryway for self-custody — via a hot wallet provider like MetaMask, Rainbow, Rabby, or some such. Let’s use MetaMask for the sake of example.

MetaMask, like most web-based browser wallets, is downloaded as an app on your device/phone or added as an extension to your browser. Once it’s on your platform of choice, technically you should be able to access it unless your device dies, you die, the internet dies, or the power grid and human-civilization-as-we-know-it-dies. Otherwise, the failure of MetaMask likely comes from either 1) a bad update that breaks the app or 2) the service is sunset for good, or 3) more commonly the default endpoint goes down.

We will explore 3) later, so let me quickly digest for the casuals what one would do if 1) or 2) were to happen. The MetaMask fox dies in a baptism of regulatory shit-catapults. Oh no, so sad, wat do :(? Well folks, this is the reason why we generate a seed phrase and keep it safesies. Let’s get mildly technical for a bit here…

1. Da “blockchain” in simplest terms can be seen as a state transition machine tracking state changes in the “computer” over time
2. Standards need to be created, implemented, and adhered to in order to have things like “tokens” represented and widely understood by all sorts of different service providers
3. Analogy: international freight shipping needs to adhere to standard dimensions of a container to capture the economies of scale in efficient transport
4. Analogy part deux: Ethereum is one of many giant oceans on Earth, and service providers are the cargo ships carrying the messages and data structures to and fro in STANDARDized containers
5. Standards are often shared between one blockchain ecosystem and another

For example, BIP-39 is a widely adopted standard that originates from Bitcoin and defines the method for generating mnemonic phrases. These phrases are then used to derive a cryptographic seed, which can be applied to generate wallets or private keys across different blockchain systems.

This is the basis for our public-private key cryptography and how ownership “happens” over digital assets. So should our favourite wallet service provider ever go down, we can take our precious little seed phrasesessies, import them into another wallet service provider that implements the BIP-39 standard, and carry on onchain.

Fun fact: this is how most people also get phished and socially engineered to enter their seed phrases into a malicious frontend. That is a guaranteed gg;no re. Never ever EVER enter your seed phrases willy nilly into anything unless you are 150,000% sure it is legit!

Decentralized or not decentralized? Decentralized! 💮

Summary: if your favourite wallet provider goes down permanently, you take your seed phrase or private key and import it into a different provider.

Hardware wallet failure, otherwise known as `wtf do we do if my Trezor battery dies?`

This section is largely a repeat of the above in terms of provider failure — you would simply import your seed phrases to another provider… with one important exception. Most people typically use hot wallets for small or otherwise inconsequential amounts of crypto. The bulk of your “vault” should otherwise go on a hardware wallet if you are serious about security. So… what happens when the internal batteries for your Trezor, Lattice1, Keystone, imKey, etc etc begin to fade? Well, you better damn have:

1. Wrote down your seed phrase in a secure manner
2. Stored your seed phrase in a secure manner, and
3. Can easily retrieve your seed phrase in a secure manner

If none of the above have been completed or can be fulfilled, well… RIP. Decentralized not so decentralized becuz u dun fuck’d up gurl.

Otherwise, if you were diligent about safeguarding your hardware wallet’s seed phrase, you can simply import it into another BIP-39 compliant wallet to carry on onchain.

Decentralized or not decentralized? Decentralized! 💮

Summary: if your favourite wallet provider goes down permanently, you take your seed phrase or private key and import it into a different provider.

I guess the crisis scenario in the first two cases are… what if the government outlaws self-custodying your assets? Well hot damn, if that happens, buckle up buckos, we’d have some strong collective civil action in response. That’s like banning owning property. Also… did the government or state ever successfully stop Tor? Or freedom of religion? Or the fucking internet?

RPC endpoint failure, otherwise known as `wtf do we do if we can’t communicate with the chain?`

Let’s examine case 3) that we mentioned in the first section. Should MetaMask fail, usually it’s because communication with the blockchain has failed. Wat mean? Wallets act as proxies for user actions. They communicate with a blockchain through an RPC endpoint. With MetaMask, the default RPC endpoint is Infura’s API (they are the creators of MM). The wonderful thing about most wallets? You can select your own. So if Infura nodes aka their RPC endpoints go down, we can point our wallet to a different one from another node provider.

There’s this wonderful service provided by DefiLlama called ChainList. They maintain a list of RPC endpoints we can point ourselves to for almost every chain that has ever been deployed.

Me personally? I love me some good ol’ decentralization. I personally run an Ethereum full node on a dedicated Dappnode machine. In casual terms… Ethereum relies on a network of specialized computers that verifies and validates the latest state changes being pinged to the blockchain. Some of these nodes stake ETH in order to have the opportunity to propose new blocks and earn a small reward for doing so. Fortunately, you don’t need to stake ETH to be a full node… which is why I run my machine without staking to support the decentralization of the network (moar nodes verifying the chain = less centralization risks to large server clusters). The point of that entire aside is that there is an added benefit to operating a node: I can access my own dedicated RPC endpoint! So, should Infura’s service ever go down, I can simply revert to my own in order to communicate with the blockchain. It’s one of my favourite features of Ethereum!

The hardware can be a bit steep, but it’s also not bank-breaking if you truly wish to run your own node. Dappnode sells dedicated Intel NUCs for ease-of-plug-and-play, but you can also run a node on your own setup provided you meet the minimum hardware requirements.

Neato!

Decentralized or not decentralized? Decentralized! 💮

Summary: there are plenty of alternative RPC endpoints for you to choose from. Failing that, you can, with some work, run your own Ethereum node for ultimate decentralization.

And for a shameless plug, check out my video for Dappnode:

dApp frontend failure, otherwise known as `oh no muh Uniswap frontend blocked access from ‘muricans`

Ah, now we’re talking. This is the meat of the decentralization argument. GLADIATORS, THIS IS WHAT WE CAME HERE FOR. Let’s say we are using a popular decentralized exchange (DEX) such as Uniswap to conduct — and let’s accapella this together again folks—

SELF-CUSTODIAL onchain trading.

Great, I am glad we are still on the same page about the most important thing in crypto™. And then let’s say big daddy gov one day decides that they don’t like their citizens participating in self-custodial trading because muh citizens need accreditation to participate. Oooooohwheeee wouldn’t that be a doozy for collective civil action. Nevertheless, we go online, and we visit https://uniswap.org. And for some fucking reason we’re not using a VPN, so we find ourselves unable to access Uniswap. Oh no, wat do?

For the casuals, this is where the magic of blockchain shines. The Uniswap frontend is only a frontend. A beautiful, pioneering frontend at that. But only a frontend and nothing more than that. The real magic of onchain is in the backend. Because the frontend is married to the immaculate, Ethereum-based backend. Because the backend of Uniswap is supported by good ol’ IMMUTABLE, PERMISSIONLESS, and UNSTOPPABLE motherfuckin’ SMART CONTRACTS.

1. Alternative 1: So if we find ourselves unable to access the frontend, we can go to https://etherscan.io, query Uniswap’s SwapRouter contract address at 0xE592427A0AEce92De3Edee1F18E0157C05861564, connect to MetaMask, and then directly write to the smart contract’s exactInputSingle function. This function allows us to specify the token addresses that we want to swap in and out, the quantities, fees, and other parameters. Big daddy gov be damned.
2. Alternative 2: we know wallets primarily communicate with the blockchain-in-the-sky via RPC endpoints. So, as long as we have access to any RPC endpoint, whether through a third-party provider or via running your own node, you can directly interact onchain. You would need a bit of programming knowledge, but you would write a script using any of the open source Ethereum libraries such as web3.js, ethers.js, or viem, and then directly query the custom RPC endpoint with the parameters of your smart contract input and output to complete the transaction. Now ofcourse, directly interacting with a smart contract with either Etherscan’s “write contract” or writing your own script is a fair bit more technical than using the made-for-casuals Uniswap frontend, but no one said hardcore decentralization was easy now, did we?
3. Alternative 3: the neat thing about composability (the ability to brick together disparate lego pieces to form anew) in the web3 paradigm is that other protocols can also leverage Uniswap’s contracts for their own benefit. For example, DEX aggregating protocols such as 1inch or Matcha, might aggregate many different DEXs, including Uniswap. This gives end users alternative frontend options to use for trading. So if Uniswap goes down, other dApps may be active that still use the Uniswap contracts on the underlying. Motha.Fucking. Smart contracts.
4. Alternative 4: understanding frontend centralization to be a risk in and of itself, the crypto community banded together to host an alternative version of the Uniswap frontend on IPFS at https://uniswap.eth.link. This way, even with a geo-blocked Uniswap frontend, users will always be able to interact with the official Uniswap contracts through a frontend that looks identical to the official one. Thank you, open source! So if a dApp is deemed important enough, it’s likely the internet will stand up to the challenge to host an alternative.

Decentralized or not decentralized? Decentralized! 💮

Summary: you can easily get around frontend failures, but you have to be willing to get a bit rough and dirty, especially if you plan to directly write to the smart contracts yourself.

Block explorer failure

A block explorer (and more specifically Etherscan) might be one of the most important tools for anyone doing anything onchain. The truth is, for most consumer-grade use of the chain, this aspect of the blockchain could be abstracted away entirely — casuals should only care about whether a transaction goes through or not. However, there are instances when being able to “explore” the chain and “see” your transactions in the format that block explorers like Etherscan presents it in is useful. Not the least of which being able to directly “read” or “write” to a smart contract in a programmatic sort-of-way is a uniquely underrated functionality of Etherscan. Nevertheless, what if 1) Etherscan went down, and 2) what if all block explorers went down?

First off, there are many alternative block explorers. So, similar to choosing a different wallet provider if your preferred service went down, you would just pivot to another. For the second case, this one is definitely a bit tougher to deal with. The indexing of blockchain data is an insanely valuable part of the stack. You have decentralized options such as The Graph providing a backstop. However for casuals, they are almost certainly not figuring out how to perform custom data queries using GraphQL. Perhaps some kind samaritan would take up the mantle to provide alternative ways to query the chain in a hypothetical ablockalypse.

This is why regional diversity of service providers, not just block explorers, across the spectrum of web3 services is so important. Regulatory attacks happen often enough on crypto. But an orchestrated regulatory attack across all jurisdictions? Unlikely. And in any case, any nation state willing to go to war against crypto would simply be shooting themselves in the foot otherwise. Why lose ground in such a pivotal megapolitical theatre? It’s like rejecting the internet on account of the possibility that you can traffick drugs with it.

Decentralized or not decentralized? Not (so) decentralized! ❌

Summary: as a proud and self-admitted hypercasual, I really don’t know how I would subsist onchain without Etherscan xD

Final score: Very decentralized! 💮

I’ve explored 5 potential failures throughout this piece: software wallets, hardware wallets, RPC endpoints, dApp frontends, and block explorers. With these being the extremely common touchpoints for the onchain casual, on the whole, I would say ⅘ readily passes the decentralized-or-not smell test. There are a variety of alternatives with which casuals can use in order to get around the failure of any one part of the stack. And failing that, it would be negligible for upstanding Ethereans to step up to the plate to create alternatives as soon as one part of the stack goes down.

So, what do you think? Are there other parts of the stack that would be worth examining? Is Ethereum decentralized enough? Are we truly on the paradigm of an unstoppable world computer? In my opinion? Yes. And that makes for an exciting future where hundreds of millions, if not billions, will be able to tap into internet of money protocols permissionlessly and equitably. LFG.

Follow me on Twitter @haochizzle or Warpcast @0xTim.eth

story time: i love the magic of onchain payments, esp. for products & services like rotki, venice.ai, SimpleLogin, just to name a few (vendors, more of this pls!). but cross-chain UX as it stands is effortful at best and untenable at worst. expecting broad adoption at this moment is comedic gold.

some vendors, like rotki, independently figure out their payment processing. others like venice.ai and SimpleLogin take the coinbase-commerce route, which, for the moment, definitely seems like the broadly adopted solution for more established offerings. that’s all fine-and-dandy until you get to the payments screen. the cognitive load — even for me, your average onchain plebeian — is TAXING (mi’lord).

from a UX perspective, these offerings presume some pretty steep prerequisites from the user:

1. 😵‍💫 know which tokens/chains you have & are on
2. 😵‍💫 know which tokens/chains the vendor accepts
3. 😵‍💫 know how to circumnavigate across chains/assets to get to the target asset

properly secured self-custody is alrdy a mega ask. now we want to levy on another one by getting users to navigate cross-chain? 😂 LOL talk about reading the room. trust me when I say this. most users, i.e. me, just want you to take our damn $$ so we can get to the product itself. if there’s too many steps in between, 9/10 times I am alrdy moving on. that’s a missed acquisition of the extremely onchain for:

1. ❌ your product
2. ❌ your community
3. ❌ crucial product feedback
4. ❌ your bottom line

gg no re

p.s. this kinda happened to me with gitcoin once

some services definitely do it better than others, e.g. ilike rotki’s classic method for picking from THEIR list of networks/tokens & generating an addy for me to send to. but you really have to be a masochist otherwise when you want to obtain an asset (for payments) in a fee-conscious way. now if you’re a product and you’re trying to appeal to your avg crypto holder? im telling you… NO SHOT. they’ll default to tradFi.

a sidebar: i have friends that still have never done anything off of mainnet (let alone ON mainnet) cuz the cross-chain UX is an absolute clusterfuck. if I extrapolate my friends as the average holder & further extrapolate their gumption for cross-chain, that’s gotta be idle capital in the excess of HUNDREDS OF MILLIONS 💸

😢 the sad part is the missed opportunities for them to experience the magic of onchain. even bigger is the missed opp for building a thriving onchain economy (outside of defi).

while some protocols (e.g. everclear (formerly connext) and across + honourable mention for my darling sygma) make the prospect of getting to the target asset much easier… it’s still a heavy cognitive load for most users besides the most native of onchain natives.

which lands us in the present day with chain abstraction™ being the latest buzz. the word of the gospel says:

“abstract away thy notion of chains and networks, and thou shallst get to the heart of the thing”

otherwise known as ➡️ input action X, ➡️ output result Y

it’s why we need projects like sprinter, the latest joint effort from the sygma and chainsafe teams. the mandate is simple: meet the users where they are (app/product level), minimize the cognitive load, and provide a seamless path for payments:

1. ✅ unify token balances
2. ✅ sus out optimal execution paths for a user’s target asset/needs
3. ✅ one signature
4. ✅ remove the need to switch networks

👆 i promise you when i was paying for rotki, venice.ai, SimpleLogin, etc. i had to do all of that on my own.

use sprinter.

i’d like to see these hypotheticals come to reality:

1️⃣ product costs $50 USDC. user has USDC spread out across multiple chains — user has no idea where. route user the fastest/most cost-efficient way to paying $50 USDC with multi-chain USDC, to the target chain. confirm.

2️⃣ same scenario above. except maybe user doesn’t have enough/any USDC. route user the fastest/most cost-efficient way to swapping to $50 USDC, using multi-chain/multi-assets. confirm.

3️⃣ Same scenario above. Except maybe even across multiple wallets? someone tell me if this is even possible?

we’re moving in the right direction. the early stage focus on infra made sense when blockspace was still a rare commodity. now let’s turn our heads to the users.

because it’s high time we stop ignoring the application layer — in effect, the users.

keep a close eye on sprinter as it progresses 👇

https://sprinter.box

We previously looked at deploying cross-chain smart contracts to the same address while paying only source chain gas/fees using the ChainSafe x Sygma Hardhat plugin called multichain-deploy. We briefly discussed how this benefits devEx so that a developer would not need to go and acquire native tokens for each chain that they would like to deploy to.

In this follow-up post, we take a look at the Foundry implementation of the multichain-deploy plugin. It is similarly developed by ChainSafe using the Sygma interoperability protocol as the backend for cross-chain deployments.

Let’s dive in.

Create an example project folder:

$ mkdir exampleProject-foundry-multichain-deploy
$ cd exampleProject-foundry-multichain-deploy

And let’s pop into VSCode:

$ code .

Run the following commands to install the Foundry toolchain locally:

$ curl -L https://foundry.paradigm.xyz | bash
$ foundryup

We will then run forge install on the multichain-deploy plugin. This will install all of the required files into the lib folder:

$ forge install chainsafe/foundry-multichain-deploy

What makes Foundry great dev tooling is its use of Solidity for both scripting and testing — no JavaScript or TypeScript required. By default on install, Foundry comes with its own example contract, “Counter.sol”, and its own example contracts for scripting and testing, “Counter.s.sol” and “Counter.t.sol” respectively.

For continuity, we will use the same Hardhat tutorial “Lock.sol” contract we used in the previous post. Let’s delete all of the “Counter”-based contracts and go ahead and create all of the related contracts to “Lock.sol”:

$ rm ./src/Counter.sol ./script/Counter.s.sol ./test/Counter.t.sol
$ touch ./src/Lock.sol ./script/Lock.s.sol ./test/Lock.t.sol

Copy and paste the contract code for “Lock.sol” (found here) into the “Lock.sol” file we just created.

NOTE: Remember to stay consistent across Solidity compiler versions.

Let’s go ahead and create our environment variable .env file in our root:

$ touch .env

And populate the .env with the key values that we will need to run this tutorial. PRIVATE_KEY should be set beginning with 0x followed by the 32-byte private key exported from a wallet like MetaMask (without <> brackets, within the quotations). CHAIN_RPC_URL should be set with the RPC URL of your choice from the chain you would like to deploy from, e.g. if you are deploying from Sepolia, then a Sepolia RPC URL. DEPLOYER_ADDRESS should be set with the owner address of the contract; typically it would be the address derived from the private key (without <> brackets, within the quotations):

PRIVATE_KEY="0x<SET_YOUR_EXPORTED_PRIVATE_KEY_HERE>"
CHAIN_RPC_URL="https://ethereum-sepolia-rpc.publicnode.com"
DEPLOYER_ADDRESS="<SET_THE_OWNER_OF_THE_CONTRACT_HERE>"

Source our .env:

$ source .env

Next, let’s write our Solidity script for deploying cross-chain. In our “Lock.s.sol” file, we will import all of our priors for Forge scripting as well as the multichain-deploy plugin:

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.20;

import {Script, console} from "forge-std/Script.sol";
import {CrosschainDeployScript} from "foundry-multichain-deploy/CrosschainDeployScript.sol";

We will inherit from the CrosschainDeployScript and then set the main entry of our Solidity script with the run function. We then call CrosschainDeployScript’s setContract function on the artifact variable, which we will set to <file name>:<contract name>, or in this case Lock.sol:Lock. This function obtains and stores the contract bytecode by artifact path:

contract LockScript is CrosschainDeployScript {
    function run() public {
      string memory artifact = "Lock.sol:Lock";
      this.setContract(artifact);

We then declare our Solidity contract’s constructor arguments as variables. In this case, one would be a uint256 for an unlockTime (which we will not be using in this example), and the other an address variable that pulls a DEPLOYER_ADDRESSfrom our .env file at root. DEPLOYER_ADDRESS is the address we will declare as the owner of this contract.

Following that, we declare the constructorArgs object and use the ABI-encode function to encode our two constructor arguments. This will deploy the contract with these arguments as our defaults:

// Assuming an unlock time in the future. Adjust the time as necessary.
    uint256 unlockTimeInTheFuture = block.timestamp + 1 days;
    address ownerAddress = vm.envAddress("DEPLOYER_ADDRESS");

// Encode constructor arguments: owner address and unlock time.
    bytes memory constructorArgs = abi.encode(ownerAddress, unlockTimeInTheFuture);

We can now write our script such that we make post-deployment contract calls to the setName function from our contract. To do so, we will declare an object for each chain we will deploy to (initDatSepolia, initDatHolesky , initDatMumbai) and use the abi.encodeWithSignature method and pass in the function we want to call (setName) and the string of the name we want to pass. Note with the code here that we set the name to the chain we are deploying to:

// Optionally, encode `initData` if you wish to call `setName` post-deployment.
// Example: setting name to the name of the chain we are deploying to
    bytes memory initDataSepolia = abi.encodeWithSignature("setName(string)", "Sepolia");
    bytes memory initDataHolesky = abi.encodeWithSignature("setName(string)", "Holesky");
    bytes memory initDataMumbai = abi.encodeWithSignature("setName(string)", "Mumbai");

We then call CrosschainDeployScript’s addDeploymentTarget function and pass in, most crucially, the target chains in quotations, and then the objects that we previously constructed:

this.addDeploymentTarget("sepolia", constructorArgs, initDataSepolia);
this.addDeploymentTarget("holesky", constructorArgs, initDataHolesky);
this.addDeploymentTarget("mumbai", constructorArgs, initDataMumbai);

The plugin comes with functions for getting fees. So we’ll set a suitable destinationGasLimit (usually should be higher to ensure cross-chain deployments succeed), and then declare the fees and totalFee object by calling the getFees function and the getTotalFeee function from CrosschainDeployScript respectively. The boolean asks whether fee isUniqePerChain. You can leave this to false for now. getFees returns an array of bridge fees, one for each deployment target while getTotalFee returns the total bridge fee:

// Adjust the gas limit as necessary
    uint256 destinationGasLimit = 600000;
    uint256[] memory fees = this.getFees(destinationGasLimit, false);
    uint256 totalFee = this.getTotalFee(destinationGasLimit, false);

In the next step, we’ll access the PRIVATE_KEY from our .env file by creating a deployerPrivateKey variable. We’ll then call the deploy function, supplying it with the previously defined parameters including the private key, fees, gas limit, and deployment options. This function call returns an array of contractAddresses, each corresponding to the deployed contract instance on different blockchains:

// Ensure PRIVATE_KEY is set in your environment variables
    uint256 deployerPrivateKey = vm.envUint("PRIVATE_KEY");
    address[] memory contractAddresses =
    this.deploy{value: totalFee}(deployerPrivateKey, fees, destinationGasLimit, false);

Let’s finally log our console with the deployed contract addresses as well as the UnlockTime that will be set (knowing this variable will make it easier for us to verify our contract on Etherscan when we have to provide our ABI-encoded constructor arguments):

    console.log("Sepolia contract address %s", contractAddresses[0]);
    console.log("Holesky contract address %s", contractAddresses[1]);
    console.log("Mumbai contract address %s", contractAddresses[2]);
    console.log("Unlock Time (in seconds since Unix epoch): %s", unlockTimeInTheFuture);
   }
}

Finally, run the script with the following forge command:

$ forge script script/Lock.s.sol:LockScript - rpc-url $CHAIN_RPC_URL - broadcast

Note: if the command doesn’t run, your environment variables may not have been set correctly. Either run source .env again or directly replace $CHAIN_RPC_URL with the RPC URL you’d like to interact with.

Success! In this particular instance, all of our contracts deployed to the same address at 0x267a26Ed02Cb4eD360c69C31324d5B0cd4dB6dDC. More crucially, this was all done from Sepolia while paying only fees on Sepolia. Your console logs should look something like this:

And for veracity, I like to verify all of my deployed contracts to check whether the setName function was fired properly post-cross-chain-deployment. I like to use either forge verify-contractor the Etherscan UI (evm target vers: paris, Yes to optimizations, 200, abi-encode your constructor arguments using HashEx, and ensure Solidity compiler versions all match). You can additionally set the solc to the same version as your contracts in the foundry.toml file.

Bonus: An example of the forge verify-contract command I used to verify my contract on Sepolia. For our constructor argument, the UNIX timestamp value of 1711647396 was deployed to the contract:

$ forge verify-contract --chain-id 11155111 --etherscan-api-key <ETHERSCAN_API_KEY> 0x267a26Ed02Cb4eD360c69C31324d5B0cd4dB6dDC src/Lock.sol:Lock --constructor-args $(cast abi-encode 'constructor(address,uint256)' '0xD31E89feccCf6f2DE10EaC92ADffF48D802b695C' 1711647396)

Proof of work: take a look below at all of our cross-chain deployments from today + all of the string name variables that were set correctly.

Sepolia:

Holesky:

Mumbai:

There you have it!

For a video walkthrough of the foundry-multichain-deploy example, check this out:

You can find the source code in the foundry-multichain-deploy repo. All code that was executed in this tutorial can be found in my repo here.

Cross-chain contract deployment (via Sygma’s generic message passing capabilities) currently costs a fixed amount of 0.001 ETH on Sygma’s testnet environment. You can take a look at fee schemes in Sygma’s Testnet environment page. So, if you make two cross-chain deployments to Mumbai and Holesky, it will cost 0.002 ETH. This fee scheme will be updated soon to be more dynamic in nature.

You can trace and track your cross-chain transactions using Sygma’s block explorer. Here’s the testnet explorer.

To summarize, thanks to Sygma’s cross-chain interoperability protocol and the handy Foundry plugin that ChainSafe has built, you can now seamlessly deploy the same smart contract across multiple blockchains under the same contract address while paying only source chain gas/fees.

Much thanks to the engineers at Sygma (Mak) and ChainSafe (Vinay, Oleksii) for guiding me through this!

The marketing will say “ours is the best/fastest/securest”. But objectively, how does each cross-chain protocol compare? I use testnet examples to approximate an analysis

[DISCLAIMER]: The following analysis uses testnet examples from various protocols using different contract implementations. This analysis does not approximate mainnet conditions using real assets. This blog post was sparked by curiosity and used exclusively as a simple investigation.

Benchmarking traditional asset bridge performance

I’ve been playing around a lot lately with cross-chain bridging examples. Working on the Sygma interoperability team as a devRel kinda necessitates deeper understanding of the cross-chain ecosystem and the protocols that dot the landscape. To start, I really wanted to understand what each protocol offers in performance from a competitive standpoint, not in the least of which how and where Sygma stands up to other offerings.

For the following exercise, I wanted to test out traditional asset bridging examples (tokens that are locked/released or burnt/mint, either in an escrow smart contract or some other). Two specific questions I wanted fairly simple and naive answers for:

1. How much gas would it cost?
2. How long would it take?

The exercise also needed to use the same source-to-destination route to get a relatively apples-to-apples comparison, especially since some chains finalize faster than others.

I compared performance between a few protocols that have working examples from their GitHub repos or docs (links inline):

1. Sygma
2. Chainlink Cross-Chain Interoperability Protocol (CCIP)
3. Axelar
4. Wormhole

[Disclaimer] Some of the mechanisms tested use pure (sic escrow) token bridges. Escrow token bridges may not necessarily be the only standard for bridging anymore. Nowadays, bridging protocols lean towards more flexible generic message passing (GMP) networks or “intent”-based solver networks, neither of which require locking (and thereby risking) ERC-20 assets in a smart contract. However, for the purposes of science and benchmarking performance, it was still worth it to do a side-by-side comparison of each protocol.

Ready? Here’s what I found:

Performance matrix

Bridges must model security

It’s important to understand that blockchain “bridges” function essentially as offchain oracles. Their primary role is to monitor events on one chain and relay them to another. A key part of this responsibility involves discerning whether these events are canonical — that is, representing the true state of affairs on the source chain — and determining the trustworthiness of these onchain computations. As such, the “performance” of a bridge is not merely a matter of speed or cost efficiency; it is intertwined with the bridge’s security model and how it establishes criteria for accepting or rejecting the results of onchain computation from any chain.

Crucially, in the current multi-party computation (MPC) setup, protocol Sygma is configured to wait for 20 block confirmations on Ethereum mainnet and testnet before processing cross-chain transactions. This block delay is to account for the possibility of reorg attacks. And to settle on this number, Sygma looked at the largest block reorg in Ethereum history and added a multiplier for safety. Other small factors may contribute to the delay, including 1) RPC delay or 2) in the case where the selected “coordinating relayer” on the Sygma MPC network temporarily goes down. But all of these account for < 30 seconds of impact. These factors combine to give Sygma a ~3 minute turnaround time on asset bridging, and as you can see from the above matrix, is highly competitive with other bridge offerings.

Ofcourse, as I’ve alluded earlier, pace of cross-chain transact is not necessarily indicative of “better”. Every bridge models its security differently, so it is important to consider the parameters and levers a protocol might adjust, or layers of security a protocol might add on top of, which may lead to longer or shorter cross-chain transact. For example, Chainlink implements three decentralized oracle networks (“DONs”), one for each cross-chain action–1) committing source Merkle proofs, 2) blessing/cursing said proofs, and 3) executing on the destination chain– while conjunctively awaiting Ethereum block finality. Axelar uses a similar approach with Ethereum block finality plus additional security logic layered on top via quadratic voting by their validator (sic relayer) network.

Don’t trust, verify

Indeed, this was a fruitful exercise to gleam insights from. And as the ancient wisdom says: don’t trust [my word], verify [for yourself]! All of the examples were relatively easy to implement and run — so you should try them out yourself! Ofcourse, I am biased towards Sygma and how quickly you can get set up to test your own Sepolia ➡️ Mumbai cross-chain token transfer :) Give it a shot when you get a chance!

If you’ve got any questions about running any of the examples, I’d be more than happy to help out. You can reach out here or via Twitter @haochizzle.

Up next, general message passing…

Appendix

Sygma source hash: Tx hash; Dest hash: Tx hash

CCIP source hash: Tx hash; Dest hash: Tx hash

Axelar source hash: Tx hash; Dest hash: Tx hash

Wormhole source hash: Tx hash; Dest hash: Tx hash

For the Foundry implementation of multichain-deploy, please see this post.

Deploying the same smart contract under the same contract address across multiple blockchains can be a boon for UX, especially for protocols/projects that need consistent addressing. However, to do so typically requires a minor but cumbersome step that materially impacts devEx — you must acquire native tokens in order to pay for the deployment cost of each chain.

To get around this problem, you can perform this same action but pay gas/fees from only one “source” chain using a Hardhat plugin developed by ChainSafe called multichain-deploy. It utilizes Sygma’s cross-chain interoperability protocol on the backend to fire the instructions for cross-chain deployment.

Setup is quite simple. Let’s dive in with a simple example where we will use Sepolia as the source chain and make cross-chain deployments to Mumbai and Holesky using Hardhat’s tutorial Lock.sol contract:

Create an example project folder:

$ mkdir exampleProject-hardhat-multichain-deploy
$ cd exampleProject-hardhat-multichain-deploy

Initialize dependency managers inside your project folder (we will use npm for the rest of the example):

$ npm init

or

$ yarn init 

Add hardhat as a development dependency to your project:

$ npm install --save-dev hardhat

Initialize the hardhat development environment:

$ npx hardhat init

Choose a JavaScript project during hardhat initialization + select all the default prompts.

Install the other dependencies we will require for the example project:

$ npm install --save-dev @nomicfoundation/hardhat-toolbox @chainsafe/hardhat-ts-artifact-plugin @nomicfoundation/hardhat-web3-v4 @chainsafe/hardhat-plugin-multichain-deploy @buildwithsygma/sygma-sdk-core dotenv

Jump into VSCode and look at the exampleProject-hardhat-multichain-deploy folder:

$ code .

Let’s modify the existing Lock.sol contract slightly. We will add a public readable string “name” to the contract:

contract Lock {
    uint public unlockTime;
    address payable public owner;
    string public name;

And modify the constructor to include some additional parameters, such as deployer / owner of the contract:

  constructor(address _owner, uint _unlockTime) payable {
        require(
            block.timestamp < _unlockTime,
            "Unlock time should be in the future"
        );

        unlockTime = _unlockTime;
        owner = payable(_owner);
    }

And add a new setName function. We will primarily use this to demonstrate post-deployment cross-chain function calls:

    function setName(string memory _name) external {
        if (bytes(name).length > 0) return;
        name = _name;
    }
}

Next, configure the Hardhat development environment by adding requirements in hardhat.config.js:

require(“@nomicfoundation/hardhat-toolbox”);
require("@chainsafe/hardhat-ts-artifact-plugin");
require("@nomicfoundation/hardhat-web3-v4");
require("@chainsafe/hardhat-plugin-multichain-deploy");
const { Environment } = require("@buildwithsygma/sygma-sdk-core");
require('dotenv').config();

We will configure the networks we want to deploy from in hardhat.config.js. This allows us to choose which “source” network we have available to deploy from with the — —network flag when we eventually run our script:

const config = {
  solidity: "0.8.19",
  networks: {
    sepolia: {
      chainId: 11155111,
      url: "https://ethereum-sepolia.publicnode.com",
      // Use process.env to access environment variables
      accounts: process.env.PK ? [process.env.PK] : [],
       },
    mumbai: {
      chainId: 80001,
      url: "https://polygon-mumbai-pokt.nodies.app",
      // Use process.env to access environment variables
      accounts: process.env.PK ? [process.env.PK] : [],
       },
    holesky: {
      chainId: 17000,
      url: "https://ethereum-holesky-rpc.publicnode.com",
      accounts: process.env.PK ? [process.env.PK] : [],
      },
  },

Note: you will need to configure the Solidity compiler versions to match.

Note #2: if you receive RPC errors during deployment, you may need to choose a different RPC URL from ChainList.

Add the multichain object from the multichain-deploy plugin and set the environment to testnet. This tells the plugin to interact with the Sygma testnet:

multichain: {
  environment: Environment.TESTNET,
  }

module.exports = config;

We will modify the default scripts/deploy.jsscript that comes with hardhat init. Make a new file called deployMultichain.js (in a scripts folder) and let’s adjust the script for cross-chain. First, we must import the multichainand web3 objects from our Hardhat plugins.

We are not adjusting much with the main() function, but take note of the fact that we must adjust the unlockTime by an order of magnitude (+60 in the original deploy.js script to + 600 in our new script). Why? The Sygma bridging protocol requires time to pass along the events across chains (currently ~5 minutes). Hence, we increase the timestamp in seconds to 600. Else, the logic will fail and the execution cross-chain will revert!

Finally, setting the deployer tells Hardhat that we will deploy from the same address (as derived from our private key) across chains:

const { multichain, web3 } = require(“hardhat”);
  async function main() {
    const currentTimestampInSeconds = Math.round(Date.now() / 1000);
    const unlockTime = BigInt(currentTimestampInSeconds + 600);
    const deployerAccounts = await web3.eth.getAccounts();
    const deployer = deployerAccounts[0];
    

We can then set the networkArguments object, which interacts with the deployMultichain function later on. We also specify which networks we will be deploying to here (sepolia, mumbai, and holesky). For each network we are deploying to, we pass Solidity constructor arguments to args, which initializes the contract with an owner and theunlockTime. initData allows us to make post-deployment contract calls to the setName Solidity function. In this example, we set the names of each chain we are deploying to using initMethodArgs:

const networkArguments = {
    sepolia: {
      args: [deployer, unlockTime],
      initData: {
        initMethodName: "setName",
        initMethodArgs: ["sepolia"],
       },
      },
mumbai: {
      args: [deployer, unlockTime],
      initData: {
        initMethodName: "setName",
        initMethodArgs: ["mumbai"],
       },
      },
holesky: {
      args: [deployer, unlockTime],
      initData: {
        initMethodName: "setName",
        initMethodArgs: ["holesky"],
       },
      },
};

We can then call the multichain object’s deployMultichain function and pass on: 1) which contract we are deploying in quotations and 2) our previously defined networkArguments. The code then waits for the deployment to complete and then retrieves and processes the deployment information. If the deployment is successful, it moves forward to obtain further details about the deployment using the transaction hash and Sygma-specific domain IDs:

const deploymentResult = await multichain.deployMultichain(“Lock”, networkArguments);

if (deploymentResult) {
    const { transactionHash, domainIDs } = deploymentResult;
    await multichain.getDeploymentInfo(transactionHash, domainIDs);
    }
 }

main().catch((error) => {
    console.error(error);
    process.exitCode = 1;
});

To run this code, you will need an exported private key from a wallet like MetaMask. Obtain that, then create a .env file in the root folder of the exampleProject-hardhat-multichain-deploy. Paste in your exported private key into the .env as such:

PK=”<your_exported_private_key_here>”

Warning: We make use of the dotenv module to manage exported private keys using an environment variable file. Please note that accidentally committing a .env file containing private keys to a wallet with real funds onto GitHub could result in the complete loss of your funds. Never expose your private keys.

Finally, you’re ready to run this script. We will test deployment from Sepolia as the “source” chain, meaning we only pay deployment gas from Sepolia. We can configure the “source” chain by adjusting the network flag:

npx hardhat run scripts/deployMultichain.js --network sepolia

Success!

For a video walkthrough of the hardhat-multichain-deploy example, take a look at this video:

You can find the source code in the hardhat-multichain-deploy repo. All code that was executed in this tutorial can be found in my repo here.

This Hardhat plugin currently supports the Sepolia, Mumbai, and Holesky testnets, with mainnet support coming soon.

Cross-chain contract deployment (via Sygma’s generic message passing capabilities) currently costs a fixed amount of 0.001 ETH on Sygma’s testnet environment. You can take a look at fee schemes in Sygma’s Testnet environment page. So, if you make two cross-chain deployments to Mumbai and Holesky, it will cost 0.002 ETH. This fee scheme will be updated soon to be more dynamic in nature.

You can trace and track your cross-chain transactions using Sygma’s block explorer. Here’s the testnet explorer.

To summarize, thanks to Sygma’s cross-chain interoperability protocol and the handy Harplugin that ChainSafe has built, you can now seamlessly deploy the same smart contract across multiple blockchains under the same contract address while paying only source chain gas/fees.

Much thanks to the engineers at Sygma and ChainSafe for guiding me through this!

In keeping with our values, we’re taking the first steps toward a more decentralized and open-source SDK with the launch of web3.unity v2.0. This is a new chapter for ChainSafe Gaming, and we’re excited to share all the details with our community! Here’s what you need to know.

The current state of web3.unity

Up to now, when a player took an action in a game made with web3.unity, a call was made to the API server, which then either performed a read query on the user’s behalf and returned the result or formed a write transaction sent back to the game for the player to sign with their wallet and broadcast.

The SDK could not function without this API intermediary. If the API went down, so too did the games relying on this service. While some of our initial decision-making was designed to get the library up and running quickly, with time, it’s become clear that a more resilient solution was needed.

Future decentralized state 🌌

Our goal has always been to make web3.unity as decentralized, flexible, and scalable as possible. In keeping with that, the launch of v2 enables client-side reads and writes directly from Unity and the RPC provider of your choice, minimizing the need for ChainSafe’s intermediary APIs.

By reducing the need for interactions with the API server, the limitation on reads and writes in any one direction gets mitigated. Instead, users can directly query the blockchain using their own local node, whether that’s through Infura via MetaMask or through a custom RPC endpoint.

This way, actions get taken as close as possible to where they’re needed, with no servers slowing things down between the wallet and the blockchain. This puts more control in the hands of the developer by reducing dependence on an API service and allowing devs to choose their own RPC providers for broadcasting transactions.

What are the benefits of v2?

Decentralizing the SDK will make blockchain games built with web3.unity faster, more scalable, and more dependable while also giving the community a greater ability to shape the future of the project 🌱

• Improves reliability — v2 gives developers the flexibility to choose the best infrastructure for their use case and avoid possible downtime while also choosing fallback options if any infra provider fails.
• Improves scalability — Game studios will be able to pick and choose the infrastructure that serves their uptime requirements.
• Improves SDK speed — Removing the API server speeds up the blockchain gaming UX since reads and writes can happen either player-side or on dedicated infrastructure.
• Improves transaction handling — Improved event listening (getting a notification immediately when a transaction goes through, rather than pinging the API server repeatedly for a status update) is one of the most consistently requested features. Decentralizing provides more responsive event handling by allowing devs and players to check transactions directly.
• Improves collaboration — Open sourcing v2 invites the gaming community to contribute meaningfully to the codebase — helping to debug, optimize, and ultimately, determine for themselves where it may be undesirable or infeasible for service providers to run infrastructure.

What does this mean for developers?

⚠️❗ This update will require code changes in projects using legacy versions of web3.unity (v1.6.x and below). In addition, projects will need to define an RPC provider as we look at sunsetting the current version of the SDK and the API server by May 2023 ❗⚠️

For existing users who need to switch, games will need to:

1. Register for a project ID (including filling out profile and project info). This is one lasting aspect of centralization, and we aim to reduce it with future updates. See this video for a tutorial on how project registration works.
2. Sign up for a node provider and get an RPC endpoint (if you aren’t already using one).
3. Update any code in your game that uses modified versions of our prefabs.
4. Test your game to ensure all functions work the same way as before.

New users will follow the same steps, with the exception of having to update any existing code.

Without these changes, people will soon be unable to make transactions within existing games. This will require some effort to refactor your code but it will also lead to payoffs in the longer term, and we’re here to help make the transition as smooth as possible.

We will provide documentation, tutorial videos, FAQs, and support via GitHub and Discord. In addition, we’ll be hosting a Discord community call on Tuesday, February 14th, 2023, to further introduce v2 and address any questions or concerns. Sign up here!

Community contribution wishlist 👥

The new version of web3.unity will be open-source, giving developers and players the opportunity to contribute to building the most flexible blockchain gaming tool to date. Want to make the SDK even better?

We invite you to tweak parameters, audit the code, and make contributions where you see fit. In particular, here are a few areas of active development:

• Writing new queries and deploying new subgraphs on The Graph for each new chain that needs to be indexed
• Creating new prefabs and features to expand the SDK’s potential
• Designing a flexible framework for supporting non-EVM chains
• Creating a new version of the SDK that supports Unreal Engine
• Improving signing UX across platforms

The bottom line in all this is that we wouldn’t be where we are today without our community. To fulfill our vision for web3.unity, we need your contributions!

A heartfelt thank you for your continued support. Let’s explore the future together.

— The ChainSafe Gaming Team

Web3.unity is an open-source gaming SDK developed by ChainSafe Gaming that connects games built with Unity to the blockchain. The library currently supports builds for web browsers (WebGL), iOS/Android mobile (WebWallet), and desktop (WebWallet). web3.unity is compatible with most EVM-based chains, letting developers easily choose and switch between them to create the best in-game experience.

Dive into the code via Github and check out the docs. Share your work on social media and tag us on Twitter @ChainSafeGaming or @ChainSafeth 👊

About ChainSafe

ChainSafe is a leading blockchain research and development firm specializing in infrastructure solutions for web3. Alongside its contributions to major ecosystems such as Ethereum, Polkadot, Filecoin, and more, ChainSafe creates solutions for developers and teams across the web3 space utilizing our expertise in gaming, bridging, NFTs, and decentralized storage. As part of its mission to build innovative products for users and improved tooling for developers, ChainSafe embodies an open source and community-oriented ethos to advance the future of the internet. To learn more, click here.

Website | Twitter | Linkedin | GitHub | Discord | YouTube | Newsletter

Open Worlds: Decentralizing the web3.unity Gaming SDK was originally published in ChainSafe on Medium, where people are continuing the conversation by highlighting and responding to this story.

Thank you to Willem Olding and Megs Doyle for their contributions to this article.

① · Introduction
② · Overview: A solution to fair, decentralized, and quality gameplay
③ · Understanding the building blocks of blockchain gaming
④ · Battle game design: Toshimon mechanics
⑤ · Technical aspects: Facilitating ‘proof of fairness’
⑥ · ChainSafe Solutions: Proposal and game development solution
⑦ · Extensibility of base game via state transition decomposition
⑧ · Conclusion: ChainSafe and Toshimon outcome
⑨ · About ChainSafe

Introduction: Full-stack solution providers will drive web3 game adoption

Advancements in blockchain technology have resulted in an entirely new era of gaming. However, the blockchain gaming industry is still in its infancy and will require stakeholders to be educated on the possibilities offered by the technology. This experimentation will allow gamers, studios, and developers alike to co-create new frontiers in gaming.

Fundamentally, the hope of employing blockchain technology in game development is to promote new ways of making games more accessible to all types of gamers. While there is an ongoing debate as to whether blockchain and web3 principles genuinely enhance the gaming experience, the advantages of web3 are clear: decentralization, provenance, sovereign ownership, composable applications, and trust-minimization frameworks.

Big-name game studios have already begun exploring blockchain integrations with use cases spanning marketplaces, multiplayer games, and collectibles. Even smaller-scale indie gaming teams are beginning to explore new primitives such as non-fungible tokens (NFTs), GameFi, and play-to-earn mechanics, as well as how each of these technological innovations can be leveraged in service of advancing today’s gaming experiences.

While the future of blockchain gaming is bright and on track to become the frontrunner for web3 adoption, there are still a number of challenges that need to be overcome. Gaming teams must develop blockchain expertise in-house or collaborate with an external organization in order to decrease the human and economic capital associated with building a blockchain-enabled game. As a result, full-stack solution providers that are experienced in multi-disciplines, multi-languages, and multi-blockchain ecosystems are crucial as development partners. They point to a future where they are increasingly relied on for the buffing effect they have on web3 game development.

As experts in infrastructure development and protocol engineering, ChainSafe has developed a reputation as one such full-stack solutions provider. This experience crosses over into ChainSafe Gaming, where ChainSafe’s gaming SDK, web3.unity deploys key infrastructure for Unity developers integrating blockchain elements into their games. The library has over 10k downloads to date. In addition, ChainSafe’s R&D department, ChainSafe Solutions, has engineered novel blockchain solutions for gaming teams. Together, the two — ChainSafe Gaming and ChainSafe Solutions — have unblocked thousands of gaming developers and studios to create games seamlessly, securely, and with dedicated support.

It was ultimately ChainSafe’s years of experience, global team of experts, and proven track record of infrastructure development that led the team at Toshimon to collaborate with ChainSafe in researching new ways to leverage blockchain for gaming.

Overview: A solution to fair, decentralized, and quality gameplay

Toshimon is a browser-based online player vs. player (PVP) battle-style trading card game (TCG) that requires the use of non-fungible tokens (NFTs) on the Ethereum/Polygon platforms to act as immutable in-game assets. The project takes after its predecessor, Pokemon, with a clear difference — bringing elements of the game design on-chain. Toshimon targets a wide berth of end-users, including collectors, traders, and gamers. Toshimon’s gamification of various aspects of blockchain allows it to double as a fun educational tool for new web3 users.

As part of the solutions engagement between both organizations, the Toshimon team approached the experts at ChainSafe with the following question:

“How can we (Toshimon) make our PVP battle system provably fair and decentralized without compromising the player experience?”

Understanding the building blocks of blockchain gaming

To better understand the need for a solution to the problem statement, it is necessary to understand the common terms associated with blockchain game design:

Provable fairness refers to a system where the fairness of a game can be cryptographically proven. This means that it should be impossible for the game’s outcome to be manipulated by any of the players or by the game’s operator. To devise such a system, some notion of (1) randomness and (2) the assurance of this randomness must be attained.

Decentralization centers around the concept of immutability and trust minimization. Decentralization mechanics endeavor to decrease the degree of trust that users place in one another and dissuade their capacity to put forth authority or command over each other in a manner that corrupts the potency of the network. Any system devised should minimize (or require zero) trust between players and additionally minimize (or require zero) trust in a third party.

Next, an understanding of compromising the player experience must be achieved. In the dial-up era of blockchain, frequent writes to a blockchain state can quickly make a game prohibitively slow and expensive to play. Excessive token approvals, endless prompts by a digital wallet such as MetaMask to sign signatures or send transactions, slow finality, and other web3-native UX could easily break player immersion.

For Toshimon, these are unimpeachable, foundational principles that needed a true web3 solution.

Battle game design: Toshimon mechanics

In order to better understand the approach ChainSafe took to solve the problem statement presented by Toshimon, it’s important to break down the game mechanics at hand. The rules of Toshimon should be familiar to anyone who has played a mainline Pokemon game. However, for anyone unfamiliar, here is a high-level overview of the Toshimon gameplay:

There are over 160 different monsters in Toshimon, each with its own set of unique statistics and 140 different moves, as well as 10 different game items. Each of these moves and items has a varied effect on the monsters in battle depending on their stats. As an added layer of complexity, some aspects of the game have a randomized component. For example, a random chance of a critical hit (or miss) and random variation for attacks.

Technical aspects: Facilitating ‘proof of fairness’ with Toshimon

As the Toshimon game mechanics do not expand beyond the 1v1 environment, there are useful two-party precedents to draw from: (1) state channels and (2) commit-reveal schemes.

(1) State channels

State channels allow two participants to conduct off-chain transactions directly with each other. Only two transactions are made on-chain: those confirming the initial and the final state. Otherwise, most of the game actions take place within the channel, which is off-chain, free, and has instant finality.

State channels were initially proposed as one scaling solution to Ethereum, where state changes are executed and validated by interested parties, minimizing computation on Ethereum’s execution layer. It has seen limited adoption and has since been supplanted by rollup technology. There are a number of reasons for this, but the primary challenges of state channels include:

1. Liveness requirements

• Participants must remain online to respond in case another player tries to cheat

2. Complexity of implementation

• For a dApp to be state channel compatible, it must be reducible to a state machine that can be implemented in a smart contract

3. Restricted participants

• Participants of a channel are fixed upon initialization and cannot be changed thereafter.

However, in the context of a 2-player game with relatively bounded complexity, state channels are a fitting implementation option and can be frequently seen being used in simple 2-player games such as tic-tac-toe and chess.

Points 1 and 3 In the above diagram are non-issues for a typical PVP card game. To put this into context, imagine two people playing cards together at a table. The games are generally quite short in duration, and the player set does not change. As a result, one unanswered question remained:

“Is it possible to implement a game with a vastly more complex ruleset, like Toshimon, in a way that can still be played within a state channel?”

(2) Commit-reveal schemes

Commit-reveal schemes allow for hidden-information games to be played in public environments such as smart contracts and state channels. Without a commit-reveal phase, the player that goes first has a disadvantage as the other player can always see their movements and respond to them accordingly. With commit-reveal, both players submit a blind commitment to their move and only reveal what it is after the protocol has locked in both players’ commitments.

This can also be used for creating shared randomness within a two-party protocol. In this scheme, both players commit to some element of randomness in addition to their moves. The contributions from both players can then be combined to determine the outcome of any move where randomness may be required (e.g., critical hits or misses). The two-state commit-reveal ensures that neither player can influence the outcome of the random moves in a predictable way and therefore gain an advantage.

While the above section aims to provide a high-level explanation of the solution ChainSafe designed for Toshimon, a more comprehensive and technical overview can be found here.

ChainSafe Solutions: Proposal and game development solution

Keeping the aforementioned primitives and constraints in mind, ChainSafe proposed improved design mechanics for the Toshimon game.

The implementation of state channels for off-chain transactions makes battles in Toshimon fast, cheap, and transaction-minimizing — one of Toshimon’s top concerns for enhanced UX. Within the state channel, an interactive commit-reveal scheme using a randomness protocol was devised to ensure a provably fair battle. The combination of these two elements allows Toshimon NFT holders to conduct off-chain battles with on-chain settlements.

For the state channel implementation, a channel contract was written that allows two players to deposit some tokens on-chain. In doing so, they agree on some initial state (e.g., which cards they are using, the health and moves available to each monster, the cryptocurrency wager, etc.) and the rules by which the state can be updated. Players then take turns signing state updates — in Toshimon’s case, these are attacks, using items, or forfeiting the game. These updates modify the agreed-upon initial state according to the game’s rules. At the end of the battle, the final state of the channel is committed to the blockchain (such as outstanding balances or the result of a battle).

Since Toshimon battles have a probability associated with each action, a source of randomness must come from a random seed committed by each player during each turn. The action + random seed must then also be revealed along with the action at the end of each turn. This scheme is called a rolling commit-reveal. A clever bit of cryptography assures randomness in a provably fair way, which is then used to dictate the outcome of each state-evolving move. This is the aforementioned randomness protocol.

Extensibility of base game via state transition decomposition

One of the key innovations of this design is observing that the state itself can contain contract addresses for small pieces of the game logic (e.g. one move or one item). As a result, there’s no need for a single registry for all of the game rules.

This has a number of very useful outcomes:

• The game logic can be decomposed into small state-mutating functions. This allows for the large ruleset to be decomposed into a collection of contracts to be deployed incrementally. Much like how cards in games such as Magic: The Gathering or Pokemon TCG can add new rules to the existing game.
• It makes the game extensible. Anyone can add new functionality at any time, but it is only allowed in a game if both players agree when initializing the channel.

This is implemented in the state by having separate contract addresses for:

• Items players may have, and
• Moves each Toshimon is capable of making

Again, it is the responsibility of the players to ensure the initial state is valid (e.g. Toshimon do not know moves they are incapable of). For players using the official Toshimon game client, this can be done automatically, but advanced players may choose to ignore this and play with their own custom rules. A useful analogy would be to imagine a group of individuals taking mainline Pokemon cards and using the printed stats and moves on each card to create their own custom variants of the game.

In the near future, on-chain games with composable game logic will meaningfully modify the in-game experience. This will provide extensibility to the base game in infinitely creative ways. This is a novel innovation for web3 gaming. In fact, it’s already being leveraged in games such as Dark Forest, where its community iterates on the game by extending and modifying the base set rule through the use of composable, interoperable smart contracts. In many ways, this is the true promise of blockchain-enabled gaming.

Conclusion: ChainSafe and Toshimon engagement outcome

ChainSafe is proud to have had the opportunity to share our expertise and experience in helping the Toshimon team understand and unlock the potential of state channels.

As a result of the schema recommended by ChainSafe, the Toshimon team went on to finish 2nd in the Grand Prize track at Polygon’s BUIDL IT Summer 2022 hackathon. This was indeed fruitful validation for ChainSafe’s research and recommendations.

Since Toshimon is built in Unity, we were also able to find natural synergies with ChainSafe Gaming’s web3.unity team. In the proposed battle system, it was suggested that transactions and state channel messages be made through the web3.unity SDK. Incidentally, Toshimon had also previously engaged with ChainSafe by bootstrapping their game development with web3.unity — thanks to the web3 sign-in and check ERC-1155 balance prefabs, they were able to effortlessly implement core infrastructure for their game.

ChainSafe Gaming has already done a lot of the groundwork for Unity NFT game developers with its web3.unity SDK. In-game minting, in-game marketplace, web3 sign-in, social sign-in, verifying Solidity messages, sending transactions, and anti-cheat voucher systems are just a few of the features already available with the latest web3.unity release. To learn more, check out NFT Minting And Marketplace For web3.unity.

If you are a gaming team eager to design and implement real web3 solutions — look no further. Enlist the help of an experienced full-stack solutions provider like ChainSafe today. Our around-the-clock and hands-on dedicated team of experts ensure that our services are suited to the needs of your project. We provide a solution for every game so that gamers can experience the new world of web3.

Everything you need starts right here.

About ChainSafe

ChainSafe is a leading blockchain research and development firm specializing in infrastructure solutions for web3. Alongside its contributions to major ecosystems such as Ethereum, Polkadot, Filecoin, and more. ChainSafe creates solutions for developers and teams across the web3 space utilizing our expertise in gaming, bridging, NFTs, and decentralized storage. As part of its mission to build innovative products for users and improved tooling for developers, ChainSafe embodies an open source and community-oriented ethos to advance the future of the internet. To learn more, click here.

Website | Twitter | Linkedin | GitHub | Discord | YouTube | Newsletter

On-Chain Game Mechanics With ChainSafe And Toshimon was originally published in ChainSafe on Medium, where people are continuing the conversation by highlighting and responding to this story.

Why should we use social logins?

Some developers feel that having social logins (e.g. Google, Facebook, Twitter, GitHub, Discord, etc.) would be a much better entrance system for users getting into the blockchain space. Some users tend to feel more comfortable having a wallet tied to a social account they already own. This helps to speed up onboarding and reduces friction when it comes to gaining new users. With a click of a button they can authorize an account and be on their way!

What is the Torus wallet?

The Torus Wallet powered by Web3Auth is a browser-enabled web wallet that seamlessly integrates into WebGL builds. Below, we’ll walk you through the wallet, how to integrate it, as well as how to use it with the web3.unity SDK.

Why use the Torus Wallet?

Torus is simple to setup and very easy to use. It allows you to login via social networks with only 1-click of a button. Through the use of various social accounts, you’re able to connect and authenticate users into your game quite easily!

An amazing dashboard full of features!

Once logged, in you’ll be presented with a very clean looking dashboard where you can see your balance, activity and various things that any user needs to manage their blockchain usage.

How to integrate the Torus Wallet into web3.unity

Using this wallet in WebGL builds is very simple! All you need to do is visit the index.js file in WebGLTemplates -> Web3 -> Index.js. Uncomment the torus JavaScript import at the top and uncomment the provider options in the connect field below.

Here’s an example of a connect field with proper configuration. You’ll see options to add an RPC, a chainID, and a networkID. Here, we’ve used goerli’s chain config with their default RPC as this is a great place to start for any developer wanting to try transactions on a free testnet. If you need goerli eth you can obtain it from the faucet for free from the Goerli PoW Faucet.

Build your project and test it out

Once the config is set, you can press Ctrl+B from Unity to create a local build and test things out. Upon using the WebGL login scene, you’ll be greeted with a pop-up allowing you to select the Torus Wallet as a form of authentication. You can see an example of this on our amazing Chicken Demo.

Making a transaction

This is extremely easy as the Torus Wallet integrates perfectly with our SDK. You can test a transaction out by walking to any of the functions and giving them a click. You’ll see a little pop up asking you to authorize the transaction like so. Just press accept and watch the magic happen! You can learn more about the Chicken Demo in our blog post Demoing web3.unity With The “Chicken Demo”.

That’s all there is to it!

Yes! it’s really that easy! We hope you enjoy having such an amazing wallet at your finger tips. We hope you develop something great and we’re proud to be integrated with these amazing teams. Keep learning and happy coding!

Welcome to the new era of #web3 gaming

web3.unity is an open-source gaming SDK developed by ChainSafe Gaming that connects games built with Unity to the blockchain. The library currently supports games built for web browsers (WebGL), iOS/Android mobile, and desktop. web3.unity is compatible with most EVM-based chains such as Ethereum, Polygon, Moonbeam, Cronos, Nervos, SKALE, and Binance Smart Chain, letting developers easily choose and switch between them to create the best in-game experience.

Dive into the code via Github and check out the docs.

Share your work on social media and tag us on Twitter @ChainSafeGaming, @ChainSafeth or on LinkedIn @ ChainSafe Systems with the hashtags #web3unity or #ChainSafeGaming. We love giving shoutouts 👊

About ChainSafe

ChainSafe is a leading blockchain research and development firm specializing in infrastructure solutions for web3. Alongside its contributions to major ecosystems such as Ethereum, Polkadot, Filecoin, and more, ChainSafe creates solutions for developers and teams across the web3 space utilizing our expertise in gaming, bridging, NFTs, and decentralized storage. As part of its mission to build innovative products for users and improved tooling for developers, ChainSafe embodies an open source and community-oriented ethos to advance the future of the internet. To learn more, click here.

Website | Twitter | Linkedin | GitHub | Discord | YouTube | Newsletter

Implementing Social Logins To web3.unity WebGL Builds was originally published in ChainSafe on Medium, where people are continuing the conversation by highlighting and responding to this story.

The following excerpt was taken from the Nov 22 OpEd I had written for ChainSafe’s newsletter “Centralization Strikes Again”. If you find this content engaging, we would love your support on our Substack! ❤️

I will not waste my reader’s precious mental capacity on the well-documented FTX collapse. Everything about the debacle invokes within me a sense of vile contempt for unchecked centralization. Worse, FTX was the wolf in sheep’s clothes — an organization playing at decentralization theatre — an act we’ve unfortunately had to see play out in semi-automatic bursts. First, with Luna/UST, and then followed by the incapacitating shots of Celsius, Three Arrows Capital, Bancor, FTX, BlockFi… you get the picture. (And I extend my condolences if you were at all caught in the crossfire.)

Yet, as one trojan horse collapsed after another, I saw a community prop itself up in defence, aided by one of the most powerful force for public good ever created — the blockchain. More crucially, the two aforementioned combined to enable a sobering self-examination: why exactly are we building this tech? Who are the bad actors? What were the warning signs? And how can we do better? This is, in fact, the bull case for FTX. Allow me to explain.

The FTX collapse saw unprecedented participation from the web3 community in citizen journalism. While traditional media outlets wrote softball puff pieces in service to their overlord SBF, the Twitter and Substack sleuths came out to play ball. Scores of citizen journalists unearthed, observed, tracked, and shared an unrelenting amount of data, with around-the-clock coverage that would put any TradMedia to shame. No stone was left unturned, as conspiratorial-level connections were discovered between FTX and the establishment — including SBF’s parents and regulators like the SEC’s Gary Gensler and US Senator Elizabeth Warren. FTX made way for the best of us to shine during crypto’s Lehman Brothers moment.

Of course, none of it would have been possible without the virtues of the always online public ledger of on-chain record. This, folks, is “privacy for the weak, transparency for the powerful” manifested: a tiny preview of what it could mean if we bridged our most important institutions on-chain — where activities like financial transactions are transmitted and recorded in a transparent and verifiable way. Is this not a public good worth preserving? It allowed our citizen journalists to track the movements of funds between exchanges, follow the FTX hack, and push the needle on innovations like mandatory proof-of-reserves and proof-of-liabilities.

And as suggested earlier, these forces enable a crucial level of self-scrutinization. It empowers us as a community to ask the important questions, keep our institutions honest, and demand the continued evolution of our space. In the well-trodden analogue of web3 as an organic, emergent biological ecosystem, the forest fire plays a crucial role in stimulating new growth. It clears away the diseased, the stagnant, the hollow in an unforgiving hellfire. Just as the previous forest fire cleared away ICO-era zombie projects which made way for newer species like Gitcoin to thrive, this fire will also clear away parasites of the FTX-variant and provide precious fertilizer for newer forms of coordination tech.

That is the silver lining. The entirety of the response has been nothing short of an incredible thing to witness, and is something that we should expect for future on-chain catastrophes. We’re speedrunning black-swan events and naturally selecting for the strongest organisms to survive. The ’08 financial collapse managed to forge a new path in humanity’s tech tree. In similar fashion, we too will come out of this for the better as a united community under the banner of decentralization.

Check out our new platform 👉 https://thecapital.io/

https://twitter.com/thecapital_io

The Bull Case For FTX was originally published in The Capital on Medium, where people are continuing the conversation by highlighting and responding to this story.

With the bear market in full bloom, it’s heartening to see the blockchain gaming community carry on hacking, building, and pioneering. This fall season has been full of hackathons and community calls and is good evidence of the gaming community’s ceaseless #ShipItMentality. For our part, ChainSafe Gaming has been keen on keeping the buidling going, so we’ve been incentivizing hackers to ideate and build with web3.unity by offering cash bounties. 👀

The requirement? Show us your best ideas for integrating your web3 Unity game with our new marketplace prefab (check out our NFT Minting And Marketplace For web3.unity announcement to learn more).

We already know the sort of capabilities our marketplace prefab could potentially unlock. Imagine a fully composable, cross-game, and cross-ecosystem World of Warcraft-style NFT Auction House that can be integrated into all Unity<->blockchain games. Of course, that’s simply one view, and there are plenty more web3-native ideas that can be implemented — ones even we haven’t thought of yet! To that end, we wanted to challenge our gaming community to cook up their wildest ideas!

Immediately following our last major version release on the Unity SDK, we held a 2-week mini-hackathon with cash prizes up to $2250 USD (or ETH equivalent)! Following that, the ChainSafe familia then showed out in full force in Bogotá, Colombia for the ETHBogota hackathon, where we offered hackers a $2k USD bounty. As we mentioned, we were keen!

ChainSafe Gaming on Twitter: "Over $2250 USD (or equivalent in ETH) is up for grabs in our 2-week hackathon!Best projects to make use of the brand new marketplace prefab wins.🥇: $1500 USD🥈: $500 USD🥉: $250 USDSubmissions due Oct 12th.Learn more: https://t.co/eVGikYL9MP / Twitter"

Over $2250 USD (or equivalent in ETH) is up for grabs in our 2-week hackathon!Best projects to make use of the brand new marketplace prefab wins.🥇: $1500 USD🥈: $500 USD🥉: $250 USDSubmissions due Oct 12th.Learn more: https://t.co/eVGikYL9MP

ChainSafe Gaming on Twitter: "Not enough minerals? 👩‍🚀Hack with web3.unity @ETHGlobal's #ETHBogota hackathon and win up to $2k USD in bounties!Our team will be ready to help with any questions in our Discord. Get in here, devs!https://t.co/Wf0znUGl8yLearn more at: https://t.co/FRFqmuWnqz pic.twitter.com/bd69aG8PT6 / Twitter"

Not enough minerals? 👩‍🚀Hack with web3.unity @ETHGlobal's #ETHBogota hackathon and win up to $2k USD in bounties!Our team will be ready to help with any questions in our Discord. Get in here, devs!https://t.co/Wf0znUGl8yLearn more at: https://t.co/FRFqmuWnqz pic.twitter.com/bd69aG8PT6

Minted, Marketed, Made. Winners of our 2-week mini hack 🏆

Let’s first start off with our 2-week mini-hackathon. We kicked it off with our Community Call extravaganza (thank you to ALL our attendees for adding to a superb conversation), which you can view again on our YouTube under Mint, Market, Make ChainSafe Gaming Community Call #5. Hackers had until Oct 12th for submissions, and when the closing bell rang, we were stoked to not only see the number of submissions, but also the quality of them.

Let’s take a look:

🥇 Reverie

In 1st place is a Spyro-inspired platforming dragon in the world of Reverie by @0xFirekeeper. Their integration of #web3unity’s marketplace prefab allows players to purchase and switch out the dragon’s skin as NFTs (on Goerli)! Grats on $1.5k USD!

Play Reverie 🕹

0xFirekeeper, a full-time developer, had a ton of great insights to share with the team after building with web3.unity. Among its many advantages, 0xFirekeeper found the ability to read and write from any contract alongside easy plug & play shorthands to be among the top benefits of using our SDK and the marketplace prefabs. Additionally, one of the main challenges that ChainSafe Gaming helped 0xFirekeeper solve when building their game is — “avoiding JavaScript/Web development and just getting straight into it.”

As for what’s next for Reverie, 0xFirekeeper will be reusing the code and optimizing it for other projects.

🥈 Forgotten Familiars

In 2nd place is Forgotten Familiars by @Riley_Page_Code, a side-scrolling wizard platformer where you can use #web3unity’s marketplace prefab to purchase different familiars with different abilities for your magic-wielding avatar. Cool! Grats on $500 USD! (Submission was made via video but #codeiskleen!)

Riley first learned about ChainSafe in the BlockJam hackathon hosted by Nervos where they won the bounty with Drawing Edge. They have been using our SDK ever since as it’s their favourite Unity<->web3 integration.

“As a developer, I’ve thought of implementing a marketplace within games before, but always dismissed the idea of it due to the difficulties of setting it up. Instead, I relied on sites such as OpenSea. I believe that the ChainSafe Gaming marketplace prefab will create countless opportunities for developers and is an amazing tool to have.”

As for the next steps, Riley will continue their web3 gaming development journey by participating in hackathons to continue upskilling and winning prizes.

🥉 The Auction House

Last but not least, in 3rd place is Auction House by @superfastgamez, an earnest attempt to integrate the ChainSafe Gaming NFT Marketplace (http://marketplace.chainsafe.io) into a play area. Grats on $250 USD!

Play The Auction House 🕹

Congratulations to all the winners! We hope that the cash prize bounty will incentivize you all to continue working on your game, or keep hacking with web3.unity in the future!

Giving all the papaya at ETHBogota 🇨🇴

In the midst of the 2-week mini-hack, the ChainSafe gang also participated in numbers at ETHBogota and Devcon VI in Colombia! It was exhilarating to experience the energy of the LatAm web3 community gathered together — and the future of the Internet is in good hands. Of course, ChainSafe Gaming had to get in on the ETHBogota hackathon action by offering up our very own bounty and having our PM Alex V on the ground and judging!

To take home the juicy $2k USD reward for hacking with web3.unity’s marketplace prefab is the @ZtowerT team! Through sweat and hard work, they managed to build an augmented reality mobile game based on tower defense vs. a horde of zombies 🧟‍♀️! In the game, players can go through the ChainSafe marketplace to buy (and list) tower defenses. What’s more, the hack idea had an element of regenerative cryptoeconomics, positing that 50% of in-game NFT purchases go towards funding LatAm scholarships. 💡 The team coins this #Play2Help.

Congratulations again to all winners!

Don’t miss our upcoming community call with SKALE: the zero gas fee network ⛽️

Next Wednesday on November 16th, 2022, the ChainSafe Gaming team will be hosting the SKALE network team in our Discord for our 6th community call! You can gain access by registering here.

For those in attendance, commemorative NFTs will be available for minting (gas not covered) on the Avalanche mainnet and tradable from the ChainSafe Marketplace 👀

See you all there!

Give back to the community

Web3.unity is a public good 🌱. If the SDK has been beneficial for you, consider giving back by spreading the word about ChainSafe, ChainSafe Gaming, and web3.unity adding our brand assets into your Unity web3 game. In return, you could receive some love on our socials, and even get spotlighted in a future blog or on our website!

Welcome to the new era of #web3 gaming

Dive into the code via Github and check out the docs.

Share your work on social media and tag us on Twitter @ChainSafeGaming, @ChainSafeth or on LinkedIn @ ChainSafe Systems with the hashtags #web3unity or #ChainSafeGaming. We love giving shoutouts 👊

About ChainSafe

ChainSafe is a leading blockchain research and development firm specializing in infrastructure solutions for web3. Alongside its contributions to major ecosystems such as Ethereum, Polkadot, Filecoin, and more, ChainSafe creates solutions for developers and teams across the web3 space utilizing our expertise in gaming, bridging, NFTs, and decentralized storage. As part of its mission to build innovative products for users and improved tooling for developers, ChainSafe embodies an open source and community-oriented ethos to advance the future of the internet. To learn more, click here.

Website | Twitter | Linkedin | GitHub | Discord | YouTube | Newsletter

Announcing Our Hackathon Winners was originally published in ChainSafe on Medium, where people are continuing the conversation by highlighting and responding to this story.