It is true that hybrid method within the design of web3 purposes cannot be ignored.
Whereas on chain sensible contracts are nice to confirm issues as a single supply of reality, it isn’t so nice for information manipulation.
That is the place hybrid comes into play.
We usually make some calculations off chain on high of synced database with on chain storages, after which mirror the outcome onto sensible contracts as quickly as we guarantee that it is legitimate.
And but, this validation just isn’t that simple and that is essentially the most susceptible level in complete utility, trigger malicious actors can all the time attempt to fake to be a sound consumer.
After all there may be a variety of approaches for this, as you realize, essentially the most well-knowns are Merkle proof and signature verification.
At the moment, I’m going to deep dive into signature verification in hybrid purposes.
I’ll extra concentrate on the general structure moderately that how we use signature verification.
If you’re not conversant in signature and EIP712, you’d higher first undergo it,
https://nftschool.dev/tutorial/lazy-minting/
Right here is the essential diagram beneath in regards to the movement.
As you may see there are 3 steps to go when it comes to frontend utility, I feel it is going to make you extra sense to overview this in frontend’s perspective since it’s truly the entry level for the customers to the applying.
Step1, as soon as consumer triggers actions on the frontend, it is going to require to signal a message.
After which it is going to make an API request to backend to be able to get signature singed by personal pockets.
Instance requests physique could be like this
{
…
userAddress: string,
userSignature: string,
}
Relating to request physique, it is going to fluctuate depends upon the actions consumer made and the applying you’re constructing.
As an example, it might embody assortment tackle, token id, value in case consumer is making an attempt to record his NFT on {the marketplace}.
Step 2, As soon as frontend will get signature from the backend facet, now it is time to make a transaction, right here simply to your be aware, consumer is definitely making a transaction via UI.
The very primary voucher struct could be one thing like this
{
consumer: tackle;
…
nonce: uint256;
expiry: uint256
signature: bytes;
}
In sensible contract, there should be some validations about signature, like if the signature is signed by the personal pockets, consumer is matched to transaction sender, nonce is right, and at last voucher just isn’t expired by checking expiry.
You’re free so as to add extra validations to your particular wants.
FYI, it is apparent to make an replace on signatures mapping and nonce as soon as signature is legitimate and you’re about to proceed your replace on states.
mapping(tackle => uint256) public nonces;
mapping(bytes => bool) public signatures;
nonces[_voucher.user]++;
signatures[_voucher.signature] = true;
Step3. There should be a outcome from the transaction, proper? whether or not it is succeed or reverted.
Provided that transaction is succeed and state variables are up to date on chain, we at the moment are able to replace a database to be able to sync with on chain.
You’ll name the API for this with request physique contains
{
…
userSignature: string, // signature by consumer
txSignature: string, // signature by personal pockets
}
For this, you must validate if transaction is succeed and states are up to date, it could be a great way to test signature mapping if txSingature is legitimate or not.
and also you may wish to do some updates in your DB after which return the outcome to the consumer.
Lastly the consumer will get the results of his motion on UI.
Thanks to your consideration, I attempted to make this as brief as attainable however on the similar time, I attempted to offer you extra sense.))
I’m going to stroll via tableland implementation for dynamic metadata which is the must-solve factor in P2E video games.
https://docs.tableland.xyz/
So keep tuned.
