Content pfp
Content
@
0 reply
0 recast
0 reaction
Joe Petrich 🟪 pfp
Joe Petrich 🟪
@jpetrich
An engineer on my team has been working on a migration of some indexed blockchain data to postgres and took our queries from an initial average latency of almost 2 seconds to under 100ms. The process to get there was fascinating, imo. Would anyone else be interested in a writeup of the optimization techniques he used?
11 replies
2 recasts
28 reactions
Pierre H. — q/dau pfp
Pierre H. — q/dau
@rektorship
I'd be interested 🙌 sharing in return our experience at Ledger serving web3 data at web2 scale :)) https://www.ledger.com/blog/serving-web3-at-web2-scale
2 replies
0 recast
1 reaction
Joe Petrich 🟪 pfp
Joe Petrich 🟪
@jpetrich
This is great! Thank you! I think what's interesting about our use case, and relevant to a lot of builders in consumer crypto, is that the subset of data we care about is actually tiny compared with indexers that need the entire chain, or multiple chains. It's a much different problem and deserves different solutions
1 reply
0 recast
2 reactions
Samuel ツ pfp
Samuel ツ
@samuellhuber.eth
what are you interested in? mainly your own transactions coming from the platform itself?
1 reply
0 recast
0 reaction
Joe Petrich 🟪 pfp
Joe Petrich 🟪
@jpetrich
Exclusively transactions that involve our single contracts' tokens on the blockchain side. Since our token ids are pseudorandom, you need to join with info from the metadata to do anything interesting, whereas lots of NFT indexers do tricks with token ID ranges to parse a contract into "collections"
1 reply
0 recast
1 reaction
Samuel ツ pfp
Samuel ツ
@samuellhuber.eth
is the pseudorandomness a design flaw then? or what was the reason/need for that? sounds easier with tokenID ranges or ERC1155 minting out custom ERC20s with new ID? (not familiar with the exact contracts thats why I am asking, forgive me)
1 reply
0 recast
0 reaction
Joe Petrich 🟪 pfp
Joe Petrich 🟪
@jpetrich
We hash the identifying metadata and use the hash as the token ID. This lets us keep the metadata offchain and lets us do "sealed packs" at mint that get revealed later without compromising integrity. It was definitely a pain before we built our own marketplace, but now it's fine.
1 reply
0 recast
0 reaction
Samuel ツ pfp
Samuel ツ
@samuellhuber.eth
And other marketplaces can use that id string anyways and then work with that? Just for mint it is way easier on you? Also love that when metadata then is public one can verify its integrity by referencing tokenid as hash of metadata 😍😍😍
1 reply
0 recast
0 reaction
Joe Petrich 🟪 pfp
Joe Petrich 🟪
@jpetrich
Since the hash is hexadecimal we convert it to base 10 for the token ID so it's really long but ERC-721 allows for a uint256 so it's compatible. It just messes with UIs that assume a small value token ID. And thank you! I'm pretty proud of that and surprised more haven't copied it.
1 reply
0 recast
0 reaction
Samuel ツ pfp
Samuel ツ
@samuellhuber.eth
ERC721 single contract? thought 1155 would fit perfectly? also copying part: many likely 1) don't know 2) don't care. As it is likely not wide spread promoted enough. Would love to share a blog post if you have one or write one :D
1 reply
0 recast
0 reaction
Joe Petrich 🟪 pfp
Joe Petrich 🟪
@jpetrich
It's ERC721. Collectors generally don't view their cards as interchangable, especially since we started with and currently only support graded cards that have unique IDs on them. Yeah you're right. I think between this and the original post's topic I need to start the Courtyard engineering @paragraph 👀
2 replies
0 recast
0 reaction