Forem: ali kim

EIP 712: A simple example using Ethers.js & Hardhat

ali kim — Fri, 12 Apr 2024 16:48:15 +0000

Several months ago, I was trying to use EIP712 to create verifiable signatures using structured data. It’s a standard way of signing structured data, so theoretically it should be super simple: Sign a message and then decode to verify it, right?

In practice, I had a tough time getting this to work. I looked at various documentation and code examples, but I noticed they all had:

different implementations of signing and verifying (decoding) signature
different implementations by ethers version
different decode implementations
overcomplicated demos
No end to end example of using ethers.js (only web3.js)

With all these little issues combined, I just couldn’t do a simple sign & verify using EIP712. I ended up wasting so much time.

Here’s a sample repo to help anyone having trouble using EIP-712. If you can’t do a simple sign & verify within 15 minutes, just use my code: https://github.com/alinobrasil/eip712_product_registry

By utilizing EIP712, you will have:

Enhanced Security: EIP712 helps prevent certain types of replay attacks and phishing attacks, thereby enhancing the security of transactions and interactions within the Ethereum ecosystem.
Improved User Experience: EIP712 provides a better user experience by enabling wallets and dApps to display transaction information in a structured, human-readable format, reducing the likelihood of user errors and increasing overall usability.
Interoperability: EIP712 facilitates interoperability between different wallets and dApps by defining a standard for how transaction data is structured and signed, thereby promoting seamless interaction and integration across the Ethereum network.

How to use The Graph to query Event data

ali kim — Thu, 02 Nov 2023 17:28:12 +0000

As a data guy, I find The Graph super awesome for developing any dapp. But I had a slightly hard time getting my subgraph to work. So here's a little guide for anyone who may find the same struggles.

Why The Graph

The Graph is GREAT for developing the frontend of a decentralized app (dapp). Here's my take on why it's so awesome and how you can quickly get up and running with it.

When your dapp needs to display some information on the state or history of something going on in your smart contract, using events instead of state variables will help save gas and overall performance. Things like tracking transaction history of an ERC20 token, borrowing/lending activity or actions like voting. You only need to read this info.

So if you design your frontend to read from logs, you can potentially let your smart contract use less storage variables. Your frontend can query from some external source with the data all prepared in a clean format.

The problem is that you need some infrastructure to collect all the relevant events, clean them up a bit and then host them somewhere for you. The Graph solves these problems in one go. Your project of indexed events is referred to as a Subgraph.

How to use The Graph

At a high level you'll need 3 things:

Set up a subgraph using their web interface and cli tool
Design a schema for how to store your data
Set up the logic to fit the event data into your schema

Part 1: Getting set up

Go to thegraph's studio: thegraph.com/studio. You'll need to connect your metamask wallet to log in.
Click the button "Create a Subgraph"
Set things up The next screen shows you the commands you need to get set up

You'll be prompted to enter a bunch of info. Here's an example from thegraph's site:

When you enter a contract address, it will be able to fetch the ABI from etherscan if the contract has been verified. So if it's your own smart contract, take the steps to verify/publish your contract. Then this graph init step will obtain the abi automatically.

It's easiest to just go with the default config by pressing enter all the way.

Part 2: Design a schema

Go into your subgraph folder. In my case, it'd be test123. Open your code editor in this folder.

The default schema generated by graph init is called schema.graphql. It creates an entity (data table) for each smart contract event but most often that will not be the schema you want to use.

How do you go about this?

Let's say your smart contract emits 2 events:

event GravatarAccepted(
  address indexed owner,
  bytes32 indexed id, 
  string displayName,
  string imageUrl
);


event GravatarDeclined(
  address indexed owner,
  bytes32 indexed id,
  string displayName,
  string imageUrl  
);

Instead of creating an entity for each event, you should try to think of the simplest way you can store this info in a way that makes sense to your front-end app.

We shouldn't need duplicate info for owner, id, displayName and imageUrl. You'd likely need just one additional field indicating whether a Gravatar was accepted or declined. So you can end up with this:

This is an over-simplified example. Later I'll show you a slightly more complex example that got me an award from The Graph (1st place in Best Use of Subgraph at ETH Global New York 2023).

Event handlers: Mapping events to your schema

This is the bulk of the work.

You'll see a ts file in the src folder named after your contract. It auto-generates a bunch of files to be able to import contract & event related event objects.

You just need to focus on the handler functions that specify what to do with each event.

In the Gravatar example above, I had 2 events:

GravatarAccepted
GravatarDeclined

Then my ts file would have handler functions called

handleGravatarAccepted
handleGravatarDeclined

The default ones only show you how to create a new record in your entity.

But that's not what we want to do for GravatarAccepted and GravatarDeclined.

For these events, we should only need to indicate whether the gravatar was accepted or not. Consider the schema defined earlier:

We should only need to update the "accepted" field.

Let's assume the contract has an event 'GravatarCreated' indicating the details (owner, displayName, imageUrl). This can simply use the default function where it creates for the our entity every time this event is created.

Then our handler functions for GravatarAccepted and GravatarDeclined should only need to locate the existing record by id and update the value for the field 'accepted'.

export function handleGravatarAccepted(event: GravatarAccepted): void {

  const gravatarId = event.params.id.toString()

  const gravatar = Gravatar.load(gravatarId) //locate entry with matching Id

  if (gravatar) {
    gravatar.accepted = true // set to true for GravatarAccepted event
    gravatar.save()
  }

}

For GravatarDeclined, the handler function would be identical except I'd just change the value to false.

That's all!

Finishing touches

One last thing before attempting to deploy your subgraph: make sure your subgraph.yaml file specifies the correct handler functions. The initially auto-generated settings are likely wrong.

Under datasources you'll see eventHandlers. We should keep only the ones we need: GravatarAccepted & GravatarDeclined. Based on our assumption that we have another event for initially creating the records, we may have GravatarCreated. So in the end it should look like this:

Alright. Time to deploy. Just follow the cli instructions you see in The Graph's studio page and you should be good to go:

Upon successful deployment, you'll see a query url that you can use from a frontend app:

You can use the playground to put together a query you want:

Then from the frontend, you just need to make a request to the url using a graphql query.

const graphqlQuery = 

{

  gravatar(last: 5) {

    id

    owner

    displayName

    imageUrl

    accepted

  }

}

;

const graphQLRequest = {

  method: 'post',

  url: 'https://api.studio.thegraph.com/query/12345/test123/0.0.26',

  data: {

    query: graphqlQuery,

  },

};

Extras:

A more complex example

In this post I've been using the Gravatar example seen on The Graph's documentation. Here's a slightly more complex example from my hackathon project at ETH Global New York. It won #1 Best Use of Subgraph.

It indexes some key info from Blend, which is Blur's lending contract for NFT-backed loans. (Blur is the largest NFT trading dex)

The events from Blend's smart contract are rather messy because they did some hacky things to optimize for gas. The result is some very unintuitive events. I simplified them into 2 entities that reflect the true context of NFT-backed lending.

My schema has a 1-to-many relationship between Liens and Loans. Each lien contains a collateralized NFT and can have its associated loan renewed/updated many times with new terms. This schema makes it much easier to work with for building an app that analyzes historical data.

I have many different events that map to these 2 entities. One of the events get re-used in many different situations so I have some complex logic for that event:

What if your smart contract is a proxy contract, and the implementation code is in another contract?

When setting up your project with graph init, it'll get the abi of the contract. If it's a proxy contract, it'll get the abi of the proxy, NOT the implementation.

To deal with this, you should specify the address of the implementation contract containing the actual logic of the smart contract, including the events you're trying to index.

For my hackathon project, this was the target contract: 0x29469395eaf6f95920e59f858042f0e28d98a20b. On etherscan, I obtained the address of the implementation contract and used it when initializing my subgraph project (graph init).

But when deploying the subgraph, you still need to point to the proxy contract, so just before deploying, you should specify the proxy contract in subgraph.yaml.

Slow indexing on Studio

While The Graph's Studio is mostly great, it is possible for you to run into performance issues. In my case, it took countless hours to index my target smart contract.

To deal with this, I specified a startBlock that's very recent, just so I could obtain some data to test with during the hackathon, though incomplete.

Some time later, the slow Studio issue was resolved. But in the heat of the moment that's what I did.

Getting started with Web3 Frontend Development: A Quick & Dirty Guide

ali kim — Wed, 12 Jul 2023 21:04:50 +0000

Developing for web3 might sound crazy, but frontend devs are very well positioned to get in on the action. There are so many 6 figure frontend dev jobs and it’s so little work to transition into web3.

An Introduction to decentralized app (dApp) Development

Much of dapp development is really on the front-end. You don’t even need to know much about smart contract development to get going. You only need to be familiar with the libraries and infrastructure necessary to prepare your app for blockchain access.

Imagine building a decentralized financial application utilizing DeFi protocols. As a front-end dev, your mission is to identify which contracts you need to access. This process doesn't require writing any code for the smart contracts themselves.

You can just think of smart contracts as apps hosted on the blockchain and you want to access their functions via APIs. Instead of a URL, you receive a smart contract address. And instead of using tools like Axios to call APIs, you use something called Ethers.js.

Utilizing Ethers.js for Smart Contract Interaction

Ethers.js enables interaction with a smart contract. After instantiating an object representing the smart contract, you can access its functions seamlessly. An example is as follows:

console.log(await walletContract.getBalance())

In this example, a smart contract wallet contains a function called getBalance.

To reach this point where you can access functions on a smart contract with one line of JavaScript code, you utilize ethers.Contract to instantiate the smart contract.

import {ethers} from 'ethers';

const walletContract = new ethers.Contract(
        deployedWalletAddress,
        WalletArtifact.abi,
        signer
    );

Here, you're importing 'ethers' and passing in three elements into ethers.Contract:

The address of the already deployed contract on the blockchain
The Application Binary Interface (ABI), which is a JSON file that outlines interaction with the smart contract (e.g., function names, parameter types)
A signer - an ethers object that contains the URL of the RPC endpoint, which sends your requests to a blockchain node

Acquiring the Address and the ABI

If you're collaborating with a team, the address and ABI will likely be provided.

When working independently, the contract address can be found on the documentation site of whoever wrote the smart contracts, along with a detailed explanation of the available functions.

You can also obtain the ABI from a block explorer website using the smart contract address. For instance, if you look up the address 0xe0d7427a900828d553A6579C842d76926a73433e on polygonscan.com, you'll find the contract code on the "Contract" page. Scroll down, and you'll find the "Contract ABI", which can be copied and saved as a JSON or JS file.

Setting Up the Signer

To set up the signer, use the following code:

const signer = provider.getSigner();

The signer is necessary for accessing write functions in the smart contract.

If you only need read functions from a smart contract, you can use the provider instead of the signer. Setting up the provider involves using Metamask:

import {ethers} from 'ethers';
import { Web3Provider } from '@ethersproject/providers';

if (typeof window.ethereum !== 'undefined') {
    const provider = new ethers.providers.Web3Provider(window.ethereum);
} else {
    // MetaMask is not available, handle accordingly
    alert('Install metamask from the Chrome webstore');
}

The above code allows users to interact with smart contracts through their Metamask wallet. Once these steps are complete, you can treat any smart contract function as a module or an API. If write operations are required, use the signer when creating an instance of the smart contract in your frontend code. For read-only functions, use the provider.

Final Remarks

While Ethereum is the most prominent blockchain, numerous others like Binance chain, Polygon, Arbitrum are either aimed at scaling Ethereum or function independently. However, from a frontend developer's perspective, this doesn't matter as these are all Ethereum Virtual Machine (EVM) compatible. So, if your code works for Ethereum, it'll function for these chains as well.

Using Ethers.js is the rawest, most traditional way. There are libraries that make some aspects of front end web3 development easier. Wagmi is a great example. It contains all sorts of react hooks to do things like check balance of an ERC20 token, see account details and even one for performing a write operation in a smart contract called useContractWrite. But getting that set up still requires you to provide an address and ABI.

Even though you can get started quickly, it's still beneficial to study smart contracts at your own pace. A deeper understanding will aid in designing better apps, as there are some aspects of Web3 development that are not so intuitive. For example, many ERC20 token operations require 2 transactions even though they seem like simple operations. As a front-end dev, it’ll take very little time to get up to speed.

How Freelancers on Decentralized Marketplaces will Pioneer the On-Chain Credit Revolution

ali kim — Sat, 01 Jul 2023 21:04:02 +0000

In an ever-evolving financial landscape, people using decentralized freelance marketplaces are playing a groundbreaking role in shaping the future of on-chain credit. Thanks to the transparent and accessible nature of blockchain technology, freelancers could be among the first individuals to borrow money on-chain without collateral. Here's why this group of people will pave way for on-chain borrowing gaining traction.

Why Employment History is King

When it comes to borrowing money, your employment info is your secret weapon. It's the main thing lenders check to see if you're good for the money. For freelancers using decentralized platforms, their work history – every gig, every payment, every review – is up there on the blockchain for all to see. It's an open book of proof that they are able to pay back.

Now think about the old-school way of checking employment history. It's an inefficient process involving contacting bosses, cross-checking pay slips all just to verify that you have a real job. With the blockchain, lenders can skip those steps and get straight to the point. They can directly check a freelancer's work history on the blockchain, making things quicker and easier for everyone involved.

To take things one step further, freelance platforms could even tokenize future earnings for established accounts. A reputable freelancer could use this to access an uncollateralized loan and it’d be in their interest to pay it back considering they’d be tarnishing their hard earned credibility if they fail to repay.

Shaking Up the Credit Scene

Traditional credit systems suck. They’re controlled by a handful of major institutions. Their systems are slow. They’re notoriously bad at keeping your data safe and it only takes a few personal details for someone to impersonate you. In the end, you even need pay money just to see your own credit score.

On-chain credit brings about a paradigm shift. In a decentralized, blockchain-based system, every action can contribute to your creditworthiness. This includes not just traditional factors like loan repayment history. Active freelance work builds strong signals for credit, but also participation in Decentralized Autonomous Organizations (DAOs) and even engagement in blockchain-based games can all count.

Each of these actions, tied to your blockchain identity, contributes to building your credit. It's a way of actively accumulating creditworthiness without needing anyone's permission or relying on a centralized authority.

Why You Should Care

For many people around the world, this can open up access to fair interest rates. In Brazil, mortgage rates are over 10%. Credit cards can legally charge 600% APY when you’re late on credit card payments. Having access to global interest rates can solve so many problems for so many people.

Even in the developed world, on-chain credit could make borrowing money more transparent and fair, reducing the chances of sketchy practices and helping more people get in on the financial action. Plus, it could make the process of checking out someone's credit history quicker and cheaper.

It also puts you in the driver's seat, giving you the power to build and keep an eye on your own credit. You won't have to pay to access your own credit score.

Looking Ahead

When freelance marketplaces gain traction, we might see the whole Decentralized Finance (DeFi) ecosystem pick up huge momentum. When freelancers start gaining access to uncollateralized on-chain credit, it'll quickly open doors for others too.

But like any groundbreaking technology, this shift will come with its own challenges, such as ensuring privacy, combating fraud, and maintaining regulatory compliance. However, there are plenty of great solutions out there already. For example. ZK proofs can verify specific claims about identity or work experience without revealing identity. It’s just a matter of building the infrastructure to create an environment where people want to work in a decentralized marketplace.

V-Lance: ETH Global Waterloo 2023 Hackathon project

My team at ETH Global Waterloo built a proof of concept on-chain professional passport. A problem with freelance platforms is that it's hard to verify anything people say. So our solution provided on-chain proof to backup claims about project & work experience.

https://ethglobal.com/showcase/v-lance-3j8qe

We built on top of TalentLayer, which is a freelance marketplace builder. We used Sismo’s zkproofs to truly verify whether someone has contributed to some pre-defined list of repositories. This allows a person to prove that they contributed without revealing their identity. This would be practical for people working with a pseudonymous identity.

We stored the result of the proofs on our own smart contract and used The Graph to query the data from our front-end.

Most people publicize their identities. For them we planned to use Ethereum Attestation Service as a means to let people have their friends and colleagues endorse them on claims about where they worked and what projects they worked on. Being a 36-hour hackathon, we ran out of time before we implemented a front-end for making attestations. But this is something we may add as we continue this project.

And we used NounsDAO’s artwork to add some style on top of TalentLayer’s default UI.

A web3 powered freelance marketplace could potentially bring better talent & client verifications than what’s seen in web2. It also enables cross-platform interoperability: Access jobs/clients on other freelance platforms. There’s no doubt about whether web3 tech can create a better product.

I feel the main challenge is in winning over traffic. Web3 freelance needs to be able to compete with Web2.

With many advancements in usability like account abstraction, there will be little friction for people to start pouring into web3 platforms.

Get started now with ComposeDB: A user-owned decentralized database on Ceramic Network

ali kim — Mon, 20 Mar 2023 19:17:32 +0000

Here you'll find a step by step guide to get your ComposeDB setup working asap.

Quick primer: ComposeDB is a decentralized database on Ceramic Network. End-users truly own their data because they're the only ones that can write/edit their own records.

This workshop repo by Ceramic packs a lot of stuff in it. It works, but if you use it as a template like I did to build your own project, you may end up running into various issues... like I did.

Here are my own notes that helped me use this repo to consistently get the required components set up and ultimately win a bounty award at ETH Denver 2023.

I've broken this down to a few sections:

Understanding ComposeDB

About the workshop repo & Issues I kept running into
Essential Terminology

How to get backend running:

Run ceramic node
Setting up your data structure
Spinning up your Graphiql server

Understanding ComposeDB

The workshop repo spins up a Decentralized Twitter app. It allows end-users to be in control of their Tweets. Elon Musk wouldn't be able to delete your profile or tweets.

You can see it running if you run "npm run dev". However, you'll see that it does a lot of things:

run ceramic node,
prepare composite files,
prepare the composite files that the decentralized twitter app needs.
spin up graphiql server (to enable graphql queries)

When they all run together in a single terminal window as multiple child processes, they crash easily and prevent your node from running properly after that.

Issues I kept running into

Here are some issues I kept running into and the solutions I got from several people at Ceramic.

unexplainable ceramic node errors
==> delete the .ceramic folder in root directory or reboot computer
.goipfs - someone else has locked the file.
==> delete the .lock file in the folder ~/.goipfs
composedb.config.json file issues
- workshop repo's config file had statestore.local-directory pointing to someone's local directory. ==> Change it to project root directory: "local-directory": ".ceramic/statestore/"
- network.name: use "testnet-clay". If that gives you issues, you can try "inmemory" and it will do everything locally.
composite issues or model not getting indexed:

==> Most likely missed a step in setting up composite file. Run the commands 1 by 1 slowly.

I ended up doing these things multiple times but once I started following my final step-by-step notes further below, I never had a problem getting set up again.

Essential Terminology

Things really only started to make sense after understanding the terminology better.

A model is essentially the schema of a data table. You define field names and types (eg. Name: String, ID: string).
A composite turns that model into JSON format, which can then be used to deploy the model to the Ceramic network.
If you have multiple models, their composite JSON files can be merged into a single file.
Users create "instances" of your model known as documents.

Both models and documents are streams on the ceramic network. You can access any model/document using their stream IDs.

Get backend running

Run ceramic node

npm run ceramic

Run this on its own so that you can easily terminate later if you need to. The workshop repo's npm run dev runs everything in the backend and the frontend together, so it runs into errors easily. By separating the ceramic node, composite setup, graphiql server and frontend, you'll run into way less issues.

Setting up data structure the first time

Installing composedb

If you have it installed using npm, then uninstall it first:

npm uninstall @composed/cli

You MUST install using pnpm. How to install pnpm depends on your OS: https://pnpm.io/installation. For linux it is...
wget -qO- https://get.pnpm.io/install.sh | ENV="$HOME/.bashrc" SHELL="$(which bash)" bash -

And you must install composedb globally:

pnpm add -g @composedb/cli

npm and yarn and npx all didn't work for me. Use pnpm. It can save you hours.

Compiling composite files

These steps are needed to feed deploy your model into the ceramic network and to generate files necessary for the graphql server and for your frontend app.

Define model (schema) in a graphql file. Name of schema, field names and data types etc. Follow the format shown in docs here or in the workshop repo.
set privatekey environment variable export DPK=yourprivatekey echo $DPK
create a composite for your model

composedb composite:create composites/termsheet.graphql --output=composite.json --ceramic-url=http://localhost:7007 --did-private-key=$DPK

If you open that output file you'll see a model ID in there identifying the model you just created.

If you have multiple composite files, you merge composites into one file.

composedb composite:merge composite1.json composite2.json --output=merged-composite.json

Deploy the single composite file. This will add all models to the model catalog

composedb composite:deploy output/composite.json --ceramic-url=http://localhost:7007 --did-private-key=$DPK

Compile composite
to enable data interactions via composeDB client, output as JSON

composedb composite:compile output/composite.json runtime-composite.json

to enable import from javascript, output as JS

composedb composite:compile output/composite.json runtime-composite.js

Your frontend app will need this runtime-composite.js file.

check if it was deployed properly:
npx composedb composite :from-model

You should be able to see your modelID somewhere in there. You can add it to your composedb config file to make sure it gets indexed.

Spin up graphql server that can interact with your model / composite:

composedb graphql:server --ceramic-url=http://localhost:7007 --graphiql runtime-composite.json --did-private-key=$DPK

That's all. You can now just focus on building your webapp. You just need a simple setup to use Ceramic and all data queries utilize graphql. Here's an example of how composeClient is used to execute graphql queries.

Ending remarks

Here are some questions I had earlier on about Ceramic & ComposeDB:

How does data live on Ceramic nodes?
==> Your data would need to be indexed by at least one node for the data to persist, so it's kind of like pinning files in ipfs. Fun fact: the data itself is stored in IPFS. ComposeDB abstracts everything away to work as a DB. In the end, anyone can spin up a node and it doesn't cost a ton of money the way various EVM chain validators do.

How do users own the data if they need to connect to a node to read/write data?
==> On the frontend, when you authenticate with authenticateCeramic, you are cryptographically signing a message with your ethereum wallet. Nodes can only write to your data on your behalf using that message.

How can I get historical data on the test network?
==> You'd need to enable historical data in the composedb config file. But to do that, you also need to change how the node keeps indexed data. Under indexing.db you'll see that it's using a sqlite server, but activating historical data would require you to setup a postgres sql server.

I think ComposeDB opens up a lot of choices for decentralized apps. It allows high speed with good enough decentralization. Over time I'm sure the backend can be packaged to be easier to manage. By then, people would be able to easily run their own nodes on their own laptops to truly own their data without relying on RPC nodes.