The past few weeks at EIF were the build phase, and it was all about implementing the different aspects of my project based on Wallet Security using MPC (multi-party computation) and ZKP (zero-knowledge proofs). It proposes a key recovery system using multi-party computation and zero-knowledge proofs to provide wallet security.

The past few weeks were all about implementing Lagrange Interpolation or Gaussian elimination in circom. Some of the things you need to know while working with circom is that it's restrictive, doesn't accept numbers beyond circom's range, it mods the negative values, and working with lots of constraints requires an understanding of how circuits work and of course how ZKP works. Overall, working with circom was a lot of fun and sleepless nights, but I wouldn't want it any other way.

The secret is split into shares in Shamir's Secret Sharing using polynomial interpolation. This polynomial interpolation can be accomplished using two methods: Lagrange interpolation and Gaussian elimination.

Lagrange interpolation is a method for constructing a polynomial of degree N-1 from a set of N elements. These N points correlate to N shares of the secret in Shamir's Secret Sharing. The Lagrange interpolation formula enables us to compute the value of the polynomial at any point, including zero, giving us the secret value. This is how the shares can be used to reconstruct the initial secret.

Gaussian elimination, on the other hand, is a method for resolving linear equation systems. In the setting of Shamir's Secret Sharing, we can represent each share as a linear equation and solve for the coefficients of the polynomial that corresponds to the secret using Gaussian elimination. We can reconstruct the secret using Lagrange interpolation once we have the polynomial values.

Both Lagrange interpolation and Gaussian elimination are used in Shamir's Secret Sharing to ensure that each share has an equal contribution to the reconstruction of the secret. These methods are also used to prevent any individual share from revealing any information about the secret, as each share only reveals information about a portion of the polynomial.

I got to integrate protocols like Push Protocol for notifications and Metamask Snaps for custom wallets.

The next few days were a deep dive into different cryptography algorithms, and I learned about different ways to implement MPC.

• Secret Sharing is a method in which a secret value is divided into multiple shares and distributed among the parties. Only by combining their interests can the parties reconstruct the secret.

• Garbled Circuits: In this method, a circuit is built with encrypted inputs and garbled gates, so that the output of each gate is determined solely by the inputs to that gate. The parties then evaluate the jumbled circuit together to acquire the final output.

• Homomorphic Encryption: This method enables computation on encrypted data without the need to decrypt it. The parties encrypt their inputs before performing operations on the encrypted data jointly to acquire the final result.

• Oblivious Transfer: This method enables one party to transfer a value to another party while remaining unaware of the value or the recipient. The recipient can choose from a number of values without revealing which one they selected.

• Secure Function Evaluation: This method involves estimating a function on the private inputs of multiple parties while keeping those inputs hidden from each other. To acquire the final output, the parties jointly evaluate the function using their private inputs and a shared randomness.

The last few days have been about integrating the contract with the front end and setting everything up, as well as finding the right encryption method for passing my keys. Overall, this is still a work in progress, and I have many more features in mind.

Although this fellowship is coming to an end, the building never stops, and I will continue to blog about my journey. Keep building, folks! :)

If you’re wondering what MPC is, MPC stands for Multiparty Computation.

Multiparty computation (MPC) is a branch of cryptography that allows multiple parties to jointly compute a function over their private inputs without revealing those inputs to each other. In other words, it allows computation on data without requiring the data to be revealed to any single participant or central authority.

MPC algorithms ensure that each participant can obtain the computation's result without knowing the other parties' data. This is accomplished through the use of cryptographic protocols such as secret sharing, homomorphic encryption, and garbled circuit

MPC paper I referred to :

https://eprint.iacr.org/2020/300.pdf

Shamir's Secret Sharing is a cryptographic algorithm that divides a secret into multiple shares and distributes them among participants. This allows the secret to be rebuilt only if a large enough number of shares are combined, but not if only a few shares are available.

Adi Shamir created the algorithm in 1979, and it is based on polynomial interpolation. The secret is first encoded as a polynomial constant term, and then a number of random points on the polynomial are generated and distributed among the participants. Any subset of the participants can combine their shares to reconstruct the polynomial and thereby recover the secret. This can be proven using Zero-Knowledge.

Zero-Knowledge-Proof (ZKP) is a cryptographic protocol that allows one party to prove to another that a particular statement is true without revealing any additional information other than the validity of the statement itself.

In a zero-knowledge proof, the party making the proof (known as the prover) can persuade the other party (known as the verifier) that a particular statement is true without revealing how they know it is true. The verifier is convinced that the statement is true because the proof is constructed in such a way that someone unfamiliar with the statement would be extremely unlikely to create a convincing proof of its truth.

https://twitter.com/RuthuRao/status/1520014511654072320?s=20

Writing these proofs in Circom has been a challenging but absolutely interesting experience. Circom is both a programming language and a toolset for building zero-knowledge proofs (ZKPs), which allows developers to design and compile circuits capable of generating ZKPs. These circuits can represent any computation that can be expressed as a directed acyclic graph (DAG), including arithmetic operations, Boolean logic, and more complex computations.

https://twitter.com/RuthuRao/status/1633830388815790092?s=20

Some of the objectives:

• Users can recover their account with just a part of their private key due to MPC.

• The other parts of the key is stored at different locations and the location is secured via ZKP.

• Allows for Secret key distribution among the user’s trusted accounts.

• Allows users to recover keys without compromising security or privacy.

• Prevents loss of funds due to lost or forgotten keys.

• Provides an additional layer of security for cryptocurrency wallets.

• Identity of the parties involved and the data they hold is unknown.

This project solves the problem of users permanently losing access to their funds due to lost or forgotten private keys.

One of the main challenges of using cryptocurrencies is the risk of losing access to funds due to lost or stolen private keys. Private keys are used to access and manage cryptocurrency funds, and if they are lost or stolen, the user may permanently lose access to their funds. Key recovery wallets with MPC and ZKP solve this problem by offering a highly secure way to recover lost or stolen private keys.

Multiple parties can work together using MPC to reconstruct a user's private key without any one party having access to the full key. ZKP can be used to verify the correctness of the reconstructed key without revealing any additional information about the key itself.

This project proposes a key recovery system using multi-party computation and zero-knowledge proofs to provide wallet security. Unlike existing projects, this system allows wallet owners to recover keys without compromising their security or privacy. The existing projects use centralised servers to store the private keys, with this approach the private keys are only revealed if user’s authorised using ZKP.

Keep an eye out in the coming weeks! You've made it to the end; please send me any articles related to the content above.

Keep building

https://github.com/route-2/challenge-5-multisig

Learnt about meta transactions and off-chain signature-based shared wallet amongst different signers.

//generates a unique hash for each transaction,
 function getTransactionHash(uint256 _nonce, address to, uint256 value, bytes memory data) public view returns (bytes32) {
        return keccak256(abi.encodePacked(address(this), chainId, _nonce, to, value, data));
    }

     // executing a transaction
    function executeTransaction(address payable to, uint256 value, bytes memory data, bytes[] memory signatures)
        public
        returns (bytes memory)
    {
        require(isOwner[msg.sender], "executeTransaction: only owners can execute");
        bytes32 _hash =  getTransactionHash(nonce, to, value, data);
        nonce++;
        uint256 validSignatures;
        address duplicateGuard;
        for (uint i = 0; i < signatures.length; i++) {
            address recovered = recover(_hash, signatures[i]);
            require(recovered > duplicateGuard, "executeTransaction: duplicate or unordered signatures");
            duplicateGuard = recovered;
            if(isOwner[recovered]){
              validSignatures++;
            }
        }

Typically, we process transactions directly on-chain, but this being a shared wallet with multiple addresses, we use Off-Chain Signature-Based Multi-Sig-Wallet.

Once the packed hash(packed hash (bytes32) is a way to represent a specific function call with its parameters as a single hash value) is generated, it can be signed by one of the signers associated with the Multisig wallet. This signature serves as a proof that the signer has authorised the execution of the corresponding function call with the specified parameters. The signature is then added to an array of signatures (bytes[] memory signatures), which contains all the signatures collected so far for the current transaction.

The user first creates a transaction that contains the necessary function call data and other parameters to carry out the desired action on the blockchain in to execute a meta transaction with an off-chain multisig wallet. The transaction is then encoded using a particular encoding technique, such as abi.encodePacked, into a packed hash (bytes32).

This packed hash is then signed by one of the signers associated with the multisig wallet using their private key. The signature is added to an array of signatures (bytes[] memory signatures), which is passed on along with the packed hash.

//Off-Chain code for getting the TX
const getSortedSigList = async (allSigs, newHash) => {
    console.log("allSigs", allSigs);

    const sigList = [];
    for (const s in allSigs) {
      console.log("SIG", allSigs[s]);
      const recover = await readContracts[contractName].recover(newHash, allSigs[s]);
      sigList.push({ signature: allSigs[s], signer: recover });
    }

    sigList.sort((a, b) => {
      return ethers.BigNumber.from(a.signer).sub(ethers.BigNumber.from(b.signer));
    });

The smart contract that receives the transaction validates the signatures in the array to ensure that they match the signers' public keys associated with the multisig wallet. If the signatures are valid, the transaction is carried out on the blockchain as the user requested.

https://github.com/route-2/challenge-7-svg

This challenge was about creating On-Chain SVG NFTs, most of the NFTs are usually IPFS hosted i.e, only the link is stored on blockchain and the metadata is stored on IPFS.

We can see this by querying the NFT contract's tokenURI. The data in SVG NFTs is stored entirely on-chain, directly in the smart contract. Instead of a link, the tokenURI returns encoded json data that includes SVG data that can be displayed in a browser.

SVG NFTs are also seen in projects like the Bored Ape Yacht Club which uses SVG NFTs to represent unique digital apes that have become highly popular collectibles,Gaming projects, such as Axie Infinity uses SVG NFTs to represent unique in-game creatures, Digital music-related SVG NFTs,Uniswap has launched LP as SVG NFTs in v3 implementation as well.

// SVG NFT data which is dynamic as the trait type 'color' and 'chubbiness' changes
function tokenURI(uint256 id) public view override returns (string memory) {
      require(_exists(id), "not exist");
      string memory name = string(abi.encodePacked('Loogie #',id.toString()));
      string memory description = string(abi.encodePacked('This Loogie is the color #',color[id].toColor(),' with a chubbiness of ',uint2str(chubbiness[id]),'!!!'));
      string memory image = Base64.encode(bytes(generateSVGofTokenById(id)));

      return
          string(
              abi.encodePacked(
                'data:application/json;base64,',
                Base64.encode(
                    bytes(
                          abi.encodePacked(
                              '{"name":"',
                              name,
                              '", "description":"',
                              description,
                              '", "external_url":"https://burnyboys.com/token/',
                              id.toString(),
                              '", "attributes": [{"trait_type": "color", "value": "#',
                              color[id].toColor(),
                              '"},{"trait_type": "chubbiness", "value": ',
                              uint2str(chubbiness[id]),
                              '}], "owner":"',
                              (uint160(ownerOf(id))).toHexString(20),
                              '", "image": "',
                              'data:image/svg+xml;base64,',
                              image,
                              '"}'
                          )
                        )
                    )
              )
          );
  }

This allows you to generate SVGs

function generateSVGofTokenById(uint256 id) internal view returns (string memory) {

    string memory svg = string(abi.encodePacked(
      '<svg width="400" height="400" xmlns="http://www.w3.org/2000/svg">',
        renderTokenById(id),
      '</svg>'
    ));

    return svg;
  }

That’s about it thank you you’ve reached the end :) Subscribe to get notified

https://speedrunethereum.com/builders/0xFEa64Acb621B94a6Bc9eAbc966427B0C3687B22A

To get an understanding how DEX really works I went through uniswap v1,v2 and v3. The newest v3 upgrade includes concentrated liquidity,Multiple fee tiers, and Customisable trading strategies.It also includes security features such as timelocks and access controls to prevent unauthorised access or manipulation of the contract.

Uniswap v3 has five fee tiers: 0.05%, 0.3%, 1%, 3%, and 5%.

The fee tier is determined by the distance between the two ticks that define the liquidity range of the position. Positions with a narrower tick range (closer ticks) earn a lower fee, while positions with a wider tick range (farther ticks) earn a higher fee.

// Allows a user to add liquidity to the pool by depositing an equal value of two tokens in a specific price range defined by `tickLower` and `tickUpper`
function mint(
        address recipient,
        int24 tickLower,
        int24 tickUpper,
        uint128 amount,
        bytes calldata data
    ) external override lock returns (uint256 amount0, uint256 amount1) {
        require(amount > 0);
        (, int256 amount0Int, int256 amount1Int) = _modifyPosition(
            ModifyPositionParams({
                owner: recipient,
                tickLower: tickLower,
                tickUpper: tickUpper,
                liquidityDelta: int256(amount).toInt128()
            })
        );

        amount0 = uint256(amount0Int);
        amount1 = uint256(amount1Int);

        uint256 balance0Before;
        uint256 balance1Before;
        if (amount0 > 0) balance0Before = balance0();
        if (amount1 > 0) balance1Before = balance1();
        IUniswapV3MintCallback(msg.sender).uniswapV3MintCallback(amount0, amount1, data);
        if (amount0 > 0) require(balance0Before.add(amount0) <= balance0(), 'M0');
        if (amount1 > 0) require(balance1Before.add(amount1) <= balance1(), 'M1');

        emit Mint(msg.sender, recipient, tickLower, tickUpper, amount, amount0, amount1);
    }

In the DEX challenge we understood how AMM works, considering x * y = k

(amount of ETH in DEX ) * ( amount of tokens in DEX ) = k

The k only changes as liquidity is added.

How does AMM really work?

• Consider An AMM has a pool of two assets, such as ETH and USDT.

• Each asset is assigned a weight, which determines its relative value in the pool. For example, if ETH has a weight of 0.6 and USDT has a weight of 0.4, then ETH is considered to be worth more than USDT in the pool.

• The product of the two assets' balances in the pool is always kept constant. So, if the pool starts with 1 ETH and 100 USDT, the product is 1*100=100.

• When a trader wants to buy or sell one of the assets, they trade with the AMM instead of another person. The AMM uses the constant product formula to determine the new price of the asset being bought or sold.

• For example, if a trader wants to buy 0.1 ETH with their USDT, the AMM will calculate the new balances of ETH and USDT that will keep the product constant. Let's say the new ETH balance is 1.1 and the new USDT balance is 90.91. The new price of ETH is then calculated by dividing the new USDT balance by the new ETH balance, which gives us 90.91/1.1=82.64 USDT per ETH.

• The AMM charges a small fee for each trade, which is added to the liquidity pool. This incentivises liquidity providers to add funds to the pool and earn a share of the trading fees.

The functions for swapping from each asset to the other are ethToToken() and tokenToEth(). Each of these functions calculates the resulting amount of output asset using the price function that looks at the ratio of the reserves vs the input asset.

The deposit() function is used to deposit ETH and a corresponding ERC20 token into liquidity pool, which creates liquidity tokens in return. It calculates the amount of tokens to deposit based on the current reserve ratio of ETH and the ERC20 token in the pool, and then transfers the tokens from the sender to the liquidity pool contract. The function also mints new liquidity tokens for the sender and updates the total liquidity of the pool.

The withdraw() function is used to withdraw liquidity from the liquidity pool. The function takes as input the “amount of liquidity tokens” to withdraw and returns the corresponding “amount of ETH and ERC20 tokens”. The function calculates the amounts to withdraw based on the current reserve ratios and updates the sender's liquidity balance and the total liquidity of the pool accordingly. Finally, the function transfers the ETH and ERC20 tokens to the sender's address.

The function price() first includes 0.3% fee to the input token, and the 0.1% fee charged by the DEX on trades.

Watch this video for more understanding

function price(
        uint256 xInput,
        uint256 xReserves,
        uint256 yReserves
    ) public view returns (uint256 yOutput) {
        uint256 xInputWithFee = xInput.mul(997);
        uint256 numerator = xInputWithFee.mul(yReserves);
        uint256 denominator = (xReserves.mul(1000)).add(xInputWithFee);
        return (numerator / denominator);
    }

Challenges I faced during this challenge was to implement the AMM in code, and passing the testcases.

Before I go ahead with the state channels challenge, here’s an overview of what state channels are ? what is the need of state channels?

As said in this tweet Ethereum is not your grandpa’s database and you don’t store everything and anything onchain.

https://twitter.com/Kautukkundan/status/1626622768249962498?s=20

A number of approaches to scaling have been developed, collectively referred to as layer-2s (L2s). One of them being the State Channels.

In State Channels users agree on the initial state and multiple transactions are done off-chain and only the final state is updated on chain, in this way we save transaction fees and also the load on network.

They enable off-chain transactions between parties in a blockchain network. They involve opening a private communication channel between two parties and executing multiple transactions off-chain without the need to record them on the blockchain immediately.

In this challenge we have a service provider , the user who is seeking service pays the service provider for the service he/she is seeking. Before seeking service the user sends in some amount to the service provider and once the user is done with seeking service i.e, wishes to update the final state, the service provider updates the final state ON-CHAIN and takes in whatever amount that was required for providing this service.

The service provider verifies the signatures before finalising the state, and the signatures are also verified off chain before providing the service using elliptic curve recover operation. We pack the message, hash it and the digest is signed which is further verified on chain by splitSignature() based on solidity’s format where it’s checked if computed signer matches the actual signer.

If you want to read more into it!

https://blog.ricmoo.com/verifying-messages-in-solidity-50a94f82b2ca

You’ve reached the end , stay tuned for my next weeks blog :)

https://speedrunethereum.com/builders/0xFEa64Acb621B94a6Bc9eAbc966427B0C3687B22A

In the Token Vendor Challenge I got to learn about the approve() in ERC20 and interaction of different contracts, it was more of getting the basics right by understanding the different functions under the ERC20 contract itself and further implementing other functions by using this contract as an instance.

A withdraw() with onlyOwner as its modifier which allows the owner to withdraw the funds from the Vendor. We had to work on the option if the users wanted to sell the tokens that they bought.

https://github.com/route-2/challenge-2-token-vendor

In the Dice game we learnt about randomization in soliidty, but also about how it is easily exploitable because instead of working on building the game itself we were asked to come up with ways of exploiting it.

https://github.com/route-2/challenge-3-dice-game

Blockchain is transparent and deterministic, meaning that once a block has been mined and added to the blockchain, its contents, including the hash value used for randomization, are public and cannot be changed. It’s easily exploitable as we only have to work on finding a pattern and using this pattern we could drain the contract.

It’s easily predictable by attackers to find a pattern and exploit the contract. This allows the attacker to manipulate the random number to their advantage and drain the funds from the contract.

In this contract we learnt about reentrancy attacks where we manipulated the original contract in another contract by implementing logic on the existing function which in turn drained the funds of target contract.

To avoid this as developers we use oracles or trusted third party services to generate random numbers which are designed to be unpredictable.Other ways to avoid would be to implement commit-and-reveal schemes or verifiable delay functions.

Commit-and-reveal-schemes is a two phase process where the hash of the number is first submitted to the smart contract by the user in the first phase and the user reveals the original number by submitting the actual value to the smart contract. The smart contract further verifies if the actual value matches to the submitted hash, this avoids the manipulation of the random number as it’s revealed only after the first phase i.e, the commit phase.

contract CommitReveal {
  bytes32 public commitHash;
  uint public revealNumber;
  bool public revealed;
  address public player;

  // Commit a number by submitting a hash of the number
  function commit(bytes32 hash) public {
    require(player == address(0), "Commitment already made");
    commitHash = hash;
    player = msg.sender;
  }

  // Reveal the original number by submitting the actual value
  function reveal(uint number) public {
    require(!revealed, "Already revealed");
    require(keccak256(abi.encodePacked(number)) == commitHash, "Invalid reveal");
    revealNumber = number;
    revealed = true;
  }

  // Check if the reveal phase is complete and return the random number
  function getNumber() public view returns (uint) {
    require(revealed, "Not revealed yet");
    return revealNumber;
  }
}

Verifiable delay functions delays the selection of a random number for a specified period of time, and in this period the contract gathers additional inputs from participants or wait for external events.This delay in generating the random number makes it difficult for someone to predict what the random number will be ahead of time.

import "@pooltogether/vdf-solidity/contracts/VDF.sol";

contract RandomNumberGenerator {
  VDF private vdf;

  constructor() {
    vdf = new VDF(1000); // set the VDF difficulty to 1000
  }

  function generateRandomNumber(uint256 input) public view returns (uint256) {
    uint256 output = vdf.evaluate(input);
    return output % 100; // return a random number between 0 and 99
  }
}

Alright that’s about it stay tuned for more!

One of the things I look forward to in this fellowship apart from the tasks itself is the discord server because it’s POPPING off with all these deep tech cool blogs/articles and the nerdy geek in me is overjoyed.

I’m nice I like to share :)

https://twitter.com/cowswap/status/1623680760522612738?s=46&t=gNak7U0Y3yIPf6wX1PPfow

https://mirror.xyz/joenrv.eth/DdbK6GR-CkeYxHoU8sKl0AFYbGeQwZcvCM5Qvzipr0g

https://mirror.xyz/0x6afeB3d9E380787e7D0a17Fc3CA764Bb885014FA/D3g-4UPRLkAnug-p6AZYfjgXWo-psaTulyu3SaL35vg

https://dev.to/spalladino/a-beginners-intro-to-coding-zero-knowledge-proofs-c56

As I received the SBT, I also received my tasks for the week and this week was all about getting the basics right. Here’s my beautiful SBT :D

https://opensea.io/assets/0xfE8321Df99317C365797c4f95C2dbd9BeEC8C694/20

The week started of with a simple NFT Challenge which was an introduction to ERC721 and a walk through Scaffold.eth, I have to admit it was annoying initially but not more annoying than building a ui for every contract.

We had to build a contract which let users mint an NFT, and which further helped me get an idea about how users can purchase and sell NFTS.This challenge also helped me understand scaffold.eth better and the entire structure of Hardhat.

The second challenge was a Decentralised Staking App, where users can work towards a cause to raise funds and the funds are further sent to a second contract, if they don’t cooperate it’s sent back to them. This challenge was tricky initially as I was figuring out the wireframe, but it got easier to execute once I got the hang of it .

The challenge was tricky as I had initially used a If else() statement but considering each and every contract is open source and is deployed on the blockchain, we have to abide by strict conditions, due to this some of the test cases weren’t passing and replacing that with require() solved it.

Some of the mistakes I did was to not really read through the whole thing and I attempted to do it on my own, well of course the perks were that I got to learn a lot but the cons were the test cases ;( but going through the test cases individually was a lot more learning again!!

I conveniently used that One sad modifier in other functions as well.

I don’t know who needs to hear this but you don’t have to use require() every where because it really restricts the contract, and a simple If-else really serves the purpose.

You’ve reached the end, and you can subscribe to see my route2 web3 ;)