DEV Community: Abdulhafiz

Operating Multichain tokens on a unilateral token bridge (BSC <> SOLANA)

Abdulhafiz — Thu, 14 Mar 2024 04:44:11 +0000

It's almost like we hear of new blockchains every other day now and they are often architecturally incompatible. It could be overwhelming to keep up with the technological innovation.

Luckily, tools are constantly being created to match the requirements of clients so that developers can make their technical wishes come true (at least before we are all replaced by AI 🤖 👨🏾‍💻)

In this article, I am going to show you can build a conceptual token bridge that achieves 1:1 parity between tokens on Binance Smart Chain (BSC) and Solana Blockchain.

Considerations:

- Token Name and Token Symbol
Since we will work with the assumption that this token is owned by the same project, I've the same name and symbol to represent both. The token name is "Useless Token" and symbol is "USELESS".

- Token Standard
USELESS (BSC) version will be BEP20
USELESS (Solana) token will be SPL-20

- Smart contracts

USELESS (BSC) will be designed using Openzeppelin's library and deployed via remix
USELESS (Solana) will be deployed to the blockchain using Metaboss tool

- Token Interaction
USELESS (BSC) will be interacted with using Ethers.js

USELESS (Solana) will be interacted with using Solana Web3 Javascript SDK and Solana Token Program Library

Steps

Creating USELESS (Solana) token deploying it on solana chain.

The first step to do this is to install solana-cli.
I used the command
solana-keygen grind --starts-with use:1 --ignore-case to create a vanity address keypair with the "use" prefix because I think it's sounds cool since our token will be "USE-less". It generated the address uSEZ...5zSo and its keypair will be saved in the working directory, I sent some SOL to it from another wallet which will be used for transaction fees later.

I created my token metadata and stored it on gitlab as a snippet, then stored it on gitlab as a snippet although it is advisable to store metadata on immutable storages like arweave. Regarding the token metadata json structure, you can read more about the different token standards well-explained on metaplex's website

By using metaboss, you need to create another metadata file in the directory you are working from with the fields "name", "symbol" and "uri". This uri must point to the raw token standard metadata file hosted on arweave or in this case, gitlab's snippet.

{
    "name": "Useless Token",
    "symbol": "USELESS",
    "uri": "https://gitlab.com/-/snippets/3686959/raw/main/useless.json"
}

AGAIN: You will create two metadata files: one that conforms with that of the spl-token token standard that would be stored in an immutable storage, and another one (above) to be used while creating our token below.

Since, I have both keypair and the "metadata pointer" files in the same directory, I used this command to mint a new token with 100m supply and 9 decimals.

metaboss create fungible -k uSEZwk76nxzBCbbPzD9Yc191wYdkQu5wN8GmV7p5zSo.json -d 9 --initial-supply 100000000 -m token.json -r https://api.mainnet-beta.solana.com

The token minted successfully.

Note: If you get the error Error: RPC response error -32002: Transaction simulation failed: Blockhash not found, just keep trying or try other node endpoints like getblock.io with my affiliate link (thank you).

Scripting with ~~NodeJS~~ Bun I am beginning to prefer Bun because of its native typescript support, so I used bun to initialize my project and installed necessary dependencies

bunx init
bun add @solana/web3.js
bun add @solana/spl-token

I created a file "useless.ts" and added the following code

// useless.ts
import { PublicKey, Connection, clusterApiUrl, Keypair, Transaction, sendAndConfirmTransaction } from '@solana/web3.js'
import { getOrCreateAssociatedTokenAccount, TOKEN_PROGRAM_ID, createTransferCheckedInstruction } from '@solana/spl-token'

const connection = new Connection(clusterApiUrl('mainnet-beta'), 'confirmed') // connection to mainnet
const secretKeyArray = await Bun.file('./uSEZwk76nxzBCbbPzD9Yc191wYdkQu5wN8GmV7p5zSo.json').json() // generated key is in the same directory as this file
const secretKey = Uint8Array.from(secretKeyArray);
const signer = Keypair.fromSecretKey(secretKey); // derived signer https://solana.com/docs/clients/javascript#quickstart


const decimals = 9 // token decimals during token creation
const uselessTokenAddressSPL = '6QWe8neoMdYUcv7LRnaBguVHTEKxC59j6Fhw8XT2pxqW' // address generated after token was minted
const mySOLWalletAddress = 'uSEZwk76nxzBCbbPzD9Yc191wYdkQu5wN8GmV7p5zSo'

// function to send solana token to given receiver and amount 
const sendSolanaToken = async (solReceiver: string, amount: number) => {
  const uselessToken = new PublicKey(uselessTokenAddressSPL)
  const mySOLWallet = new PublicKey(mySOLWalletAddress)
  const receiver = new PublicKey(solReceiver)

  // this is important because solana spl-tokens use different accounts
  // to hold tokens for different wallets, so if the receiving account
  // doesn't already have an associated account for this token, we will have to create it for them
  // so that they can receive it (Read more at https://spl.solana.com/token#example-transferring-tokens-to-another-user)
  const fromAccount = await getOrCreateAssociatedTokenAccount(connection, signer, uselessToken, mySOLWallet)
  const toAccount = await getOrCreateAssociatedTokenAccount(connection, signer, uselessToken, receiver)

  try {
    // to ensure we are attempting to add our transaction after a previously finalized block
    const latestBlock = await connection.getLatestBlockhash('finalized');
    const tx = new Transaction().add(
      createTransferCheckedInstruction(
        fromAccount.address, uselessToken, toAccount.address, mySOLWallet, amount, decimals, undefined, TOKEN_PROGRAM_ID
      )
    )
    tx.recentBlockhash = latestBlock.blockhash
    tx.lastValidBlockHeight = latestBlock.lastValidBlockHeight

    // broadcast the transaction
    const txHash = await sendAndConfirmTransaction(connection, tx, [signer])
    // log transaction hash
    console.log(txHash)
    return txHash;
  } catch (e) {
    // log error
    console.log('error occurred here', e)
  }
}

My script can now send "USELESS" token to any valid solana address but I wanted it to send whenever I receive a similar amount on BSC. And to achieve this, it will lead us to...

Create USELESS (BSC) token and deploy it on Binance Smart Chain network.

As you see in the image above, I have imported the ERC20 libraries I wanted. (ERC20Permit is optional but recommended) then deployed it on the network at 0x84109ff145Df1F2f3df12AD57BC104d96E034f58.

But this is not enough as I need the users to submit their solana address whenever they are making a deposit so that my bridge script can pick it up automatically and send then the equivalent spl-token. I deployed the contract for this successfully at UselessPurseBSC

And then I modified my "useless.ts" script accordingly by including the new lines

// useless.ts
...
import { Contract, JsonRpcProvider } from 'ethers'
const uselessPurseABI = [   {
  "anonymous": false,
  "inputs": [
    {
      "indexed": false,
      "internalType": "address",
      "name": "bscSender",
      "type": "address"
    },
    {
      "indexed": false,
      "internalType": "uint256",
      "name": "amount",
      "type": "uint256"
    },
    {
      "indexed": false,
      "internalType": "string",
      "name": "solReceiver",
      "type": "string"
    }
  ],
  "name": "Deposit",
  "type": "event"
}]
const uselessTokenPurseBSC = '0x3B156913F104287eb1cA166C3cf5F8F0f59e561E'
const bscConnection = new JsonRpcProvider('https://go.getblock.io/<api-key>')
const uselessPurse = new Contract(uselessTokenPurseBSC, uselessPurseABI, bscConnection)
...

// this will watch for the deposit event on our UselessPurse contract 
// this is the entry point to the bridge
uselessPurse.on('Deposit', async(_: string, amount: string, receiver: string) =>  {
  // a good idea would be to queue responses first or store them in a database and then fulfill them automatically at intervals later on
  // because of many potential problems including as rate-limiting on the node, invalid solana address,
// exhausted funds for solana token transfer, 
// any other unforeseen technical error

  // fulfill the token transfer
  await sendSolanaToken(receiver, Number(amount))
})

With the above done, I could now run my bridge script using

bun --watch useless.ts

Using a client side dApp or bscscan explorer, users can deposit tokens into the UselessPurse contract and they will get the equivalent in their provided solana wallet.

Conclusion:
The use of crypto bridge is important because of the consistent evolution of blockchain technology and the need for projects and startups to make their utility tokens interoperable with multiple chains. In this article, we built a simple unilateral bridge that accepts tokens deposits on BSC network and automatically transfer equivalent amount on solana network.

IMPORTANT None of the contracts in this tutorial has been audited and therefore cannot be guaranteed to be safe to use but serve well as good reference for educational material.

Further reading:
A crash course in crypto currency bridges
Wormhole Blog

References:
Solana Clients
SPL Token
Metaboss

Node (Affiliate Link)
Getblock

Repo:
cross chain token repo

Compile Solidity In The Browser

Abdulhafiz — Mon, 03 Oct 2022 15:40:21 +0000

Like me, if you have run into issues using Browser-solc when trying to create an app that could compile solidity in the client using ReactJS, this article is for you. We'll see how to use of @agnostico/browser-solidity-compiler to acheive our result shortly, getting rid of common issues you are likely to face.

There are many reasons why you may want to compile a solidity smart contract in the browser; Maybe you are building the next remix or you are building an entirely different application and you simply want to have the client fully take control of what is compiled as with the case with what I am building, Agnostico.

Since the eth_compile API was deprecated, the available alternatives (Solc-JS and the extended Browser-Solc) work best in a server setup or is tightly coupled to the HTML DOM, they are not so flexible to work with in modern Javascript library environment such as ReactJS, well at least, not so straight-forward. This will make your application throw tantrums as you develop with them which, from my experience, is a terrible developer experience.

To allow others build their applications with ease, I built on the provisions of solcjs and created a package that can work efficiently in such development environments (and with typescript support). It uses webworkers under the hood to offload heavy compilation computations from our main thread. Let's take a look at it in action.

The project is available in the example branch of the repo. I will explain how it works here with snippets so let's get to it.

The example repository is built with create-react-app, and to install our package, we run

npm i @agnostico/browser-solidity-compiler

Using the package in our application,

// App.tsx
...
import {
  getCompilerVersions,
  solidityCompiler,
} from '@agnostico/browser-solidity-compiler';
...

the getCompilerVersions is an async operation that fetches the list of existing solidity versions from https://binaries.soliditylang.org/bin/list.json.

// App.tsx
...
const loadVersions = async () => {
 const { releases, latestRelease, builds } = await getCompilerVersions()
};

// Load versions immediately page is mounted
useEffect(() => {
 (async () => { 
   await loadVersions() 
  })();
 }, []);
...

Our returned object looks like this

And then to compile our contracts, we select the we simply pass the required arguments into the compiler object. Our version will look similar to this if we are not using a template literal: https://binaries.soliditylang.org/bin/soljson-v0.8.17+commit.8df45f5f.js (If we are using solidity version 0.8.17). But to make it dynamic in cases where the user can switch between versions, we implement like this.

// App.tsx
...
const compiled = (await solidityCompiler({ 
version: `https://binaries.soliditylang.org/bin/${usingVersion}`,
 contractBody: content,
 options,
}));
...

The contractBody is the string of the contract(s) to be compiled. while options the optimization object. It is optional. For example, you could have optimization looking like this

options.optimizer = {
  enabled: true,
  runs: 200,
};

Our contracts in the example repo was returned in the compiled variable, stored in state and accessed this way

// App.tsx
Object.keys(compiledContract?.contracts?.Compiled_Contracts).map((cont) => (
  <div key={cont}>
   <p>{cont}</p>

  <span>Bytecode</span>: <small>
{
                      compiledContract?.contracts?.Compiled_Contracts[cont]?.evm?.bytecode?.object
 }
   </small>
 </div>
 )
)

The contract(s) are stored in a property of the returned object called Compiled_Contracts where we can access their information such as the abi or bytecode and shown above.

Reference:
Solc-JS
@agnostico/browser-solidity-compiler

Creating an ERC20/BEP20 token without libraries with testing (part 1)

Abdulhafiz — Wed, 25 May 2022 14:54:26 +0000

The aim of this tutorial is to demonstrate the creation of a ERC20-compliant token. The code is not audited and should not be used in production.

Requirements:

Basic knowledge of solidity.
An internet browser.

If you are completely new to solidity, you may wish to check out these resources: ethereum.org or if you prefer videos like me, you can check out Solidity Programmer on youtube.

Let's begin coding, navigate to from your browser to https://remix.ethereum.org.

Remix IDE allows developing, deploying and administering smart contracts for Ethereum like blockchains.

In remix, we'll create a new file in our workspace, let's call it RawToken.sol

Explanation:

1- We started by specifying the license and version of solidity we want to write in.[1].

2- We defined the events that will be emitted to the chain when some actions are performed on our token contract.

Approval - is emitted when an account changes the amount that another account can spend from its balance. e.g when you a smart contract should automatically transfer an amount from your account to itself.
Transfer - is emitted when token transfer is successful.

3- These values are not expected to change throughout the lifetime of our contract. (This requirement is specific to our example contract).

NAME - token name. In this example, token name is "ERC20 Token".
SYMBOL - token symbol. In this example, token symbol is "T-O-K-E-N".
_decimals - token decimals.
_totalSupply- total supply of token. We won't be minting more tokens after our token is deployed.

4- We track some of the variables that relate to transfers and balance

_balances - tracks the balance of token(s) owned by an account
_allowances - tracks the amount of tokens another account has approved for it to spend on its behalf.

5- Constructor
During our contract construction, we supplied two arguments and also mint all the tokens we want to the deployer's account.

supply - The exact amount of tokens we want to mint. e.g if we want 1,000,000 tokens, we will specify "1000000"
_decimal - The decimals we want our token to have. Each token will be calculated using n * 10 ^ _decimal.

6- A set of functions that return the read-only variables and/or constants.

totalSupply - Returns the total supply of the token in existence.
decimals - Returns the decimals of the token.
symbol - Returns the token symbol.
name - Returns the token's name.
balanceOf - Tracks the amount of tokens owned by an account.
allowance - Tracks the allowance approved by an account for another account.

7- A set of functions that mutates the state of our token contract.

approve - Used by an account to increase or decrease the amount of tokens the spender account can spend on its behalf. Very useful when interacting with dApps.
transfer - Lets an account transfer an amount of tokens from its balance or allowance to another account.
transferFrom - Enables an account make a transfer to a beneficiary from the balance of another account. Relies on the allowance provided by the from account.
_transferFrom - Handles the transfer logic while updating the balances of the sender and receiver.

Deployment

1- The token is being deployed in the local virtual environment provided by remix IDE.
2- An account also provided by remix starts with 0x5B3 and ends with eddC4 will be used to deploy the contract.
3- The constructor arguments are provided during contract construction. Here, we are minting exactly 5 million tokens and we have requested that the contract uses 9 decimals.

4- balanceOf function returns the balance of the deployer which in our case, is the total supply of the token since we "minted" this amount to the deployer inside the contract's constructor.
5- decimals returns correct value of 9.
6- name returns correct value ERC20 Token.
7- symbol returns the correct value of "T-O-K-E-N".
8- totalSupply returns the total supply of the tokens which is equal to the amount minted to the deployer explained earlier.

Conclusion:
This tutorial demonstrates how to create an ERC20-compliant token. This is not advised to be used in production as existing implementation such as openzeppelin is battle-tested and audited by various projects.

In the subsequent article to this, I will be moving the code to VSCode and use hardhat environment to compile, test and deploy

References: