Nice work, visualization with the diagrams help a lot understanding the content. Another interesting way to handle an allowlist, in a more dynamic way, is via off chain signers. This allows you to update the list during distribution without having to update your root.
i don't think we need to loop, because you can just index the uint that you need directly, right? like in the example with 525. we don't have to scan the array, we can just do 525//256=2 and access index 2 in the array
Great work Jordan, really enjoyed the video. I have a few questions: - The frontend for the final airdrop claimer needs to be as simple as possible, my understanding is that the only thing he would need to do is click on a claim button which would provide his address and the computation for research of address, associated index and claimable value will be done automatically + sibling hashes provided automatically. Hence just needing a claim button can enable a user to generate a valid proof right? - In tree.json you are showing the tree + associated values, where is that stored? I assume on chain because it would be needed for proof generation. - If it is indeed stored on chain it would also mean that all addresses + their associated claimable balance would be visible on chain which could lead to some problems ( anonymity, security, ect... ) is there a way to mitigate that ? I hope I was clear and thanks for your content 👍
Thanks! Yes, the front-end that the user sees should just have a "claim" button. But in the background that front-end should talk to a server (or maybe do this all in browser) which fetches the index number for the address plus sibling hashes etc. Then the client's browser can build the tx via metamask or w/e. The contents of tree.json would *not* be stored onchain. The only thing which goes onchain is the root hash. All the leaves and intermediate hashes are offchain, and will be used when users submit proofs. So the tree.json would likely sit on a server which talks to the airdrop claim front-end. There shouldn't be any security issue with knowing the full tree. At least, there's no hack you can do assuming people secure their private keys properly. You could obscure all the tree leaves and only share intermediate hashes if you wanted to provide some privacy. Cheers!
Nice work, visualization with the diagrams help a lot understanding the content.
Another interesting way to handle an allowlist, in a more dynamic way, is via off chain signers. This allows you to update the list during distribution without having to update your root.
Thanks Lars :)
The author has to be a teacher, this is clearly the BEST explanation and scheme specifically Is sickkkk
Watched a bunch of other videos and only this one could help me understand merkle tree
31:05 the double hashing is to prevent something call a preimage attack
Hey Jordan! Just wanna says thanks for all the awesome content that you've been putting out.
Just realized that I sounded like a bot
Thank you! I appreciate the support 🙏🏻
I can tell you're real 🫡
fantastic video, brilliant work. thanks!
for the dynamic array whenever you will need to find a value you have to loop throught the mapping which gas non-efficient
i don't think we need to loop, because you can just index the uint that you need directly, right? like in the example with 525. we don't have to scan the array, we can just do 525//256=2 and access index 2 in the array
All videos are of high quality. Thanks a lot.
Thank you for your hard work, Ser. Please keep going.
I shall 🫡
Hey Jordan, I was studiying the Uniswap V3 codebase and was stuck at tick bitmap. This video helped me a lot, thanks!
Great work Jordan, really enjoyed the video. I have a few questions:
- The frontend for the final airdrop claimer needs to be as simple as possible, my understanding is that the only thing he would need to do is click on a claim button which would provide his address and the computation for research of address, associated index and claimable value will be done automatically + sibling hashes provided automatically. Hence just needing a claim button can enable a user to generate a valid proof right?
- In tree.json you are showing the tree + associated values, where is that stored? I assume on chain because it would be needed for proof generation.
- If it is indeed stored on chain it would also mean that all addresses + their associated claimable balance would be visible on chain which could lead to some problems ( anonymity, security, ect... ) is there a way to mitigate that ?
I hope I was clear and thanks for your content 👍
Thanks!
Yes, the front-end that the user sees should just have a "claim" button. But in the background that front-end should talk to a server (or maybe do this all in browser) which fetches the index number for the address plus sibling hashes etc. Then the client's browser can build the tx via metamask or w/e.
The contents of tree.json would *not* be stored onchain. The only thing which goes onchain is the root hash. All the leaves and intermediate hashes are offchain, and will be used when users submit proofs. So the tree.json would likely sit on a server which talks to the airdrop claim front-end.
There shouldn't be any security issue with knowing the full tree. At least, there's no hack you can do assuming people secure their private keys properly. You could obscure all the tree leaves and only share intermediate hashes if you wanted to provide some privacy.
Cheers!
Trust me broo your will channel get more and more subscribes as you explain everything in diagram
Bless. Thanks man. I'm not going to stop! So much more stuff I want to draw
Extremely well explained!
Thank you for the great explanation!
Amazing content as always. Would love to see a video about ERC4337!
Definitely in the backlog 🌞
The legend has posted again
😂
can we do the same implementation using verkle tree?
Awesome explaination bro
Thank u ✨
what are you writing on the desk behind you ?
your calendar and plans ?
Yeah pretty much. The whiteboard has video topics on it.
Again Thanks broo
Great work 👍
cute and knowledgeable ...!