frangio

@frangio

109 Following

158 Followers

frangio pfp

On web in macos, using the trackpad to navigate through history (2-finger swipe left/right) doesn't work.

0 reply

0 recast

1 reaction

frangio pfp

This but using Sourcegraph is better in my experience: https://sourcegraph.com/search?q=context:global+repo:tintinweb/smart-contract-sanctuary+file:/mainnet/+%22function+tokenURI%28%29%22&patternType=keyword&case=yes&sm=0

0 reply

0 recast

2 reactions

frangio pfp

I think it is: PUSH5 0x0100000001 MUL DUP1 PUSH1 0x08 SHR PUSH4 0xff00ff00 AND SWAP1 PUSH1 0x18 SHR PUSH3 0xff00ff AND OR

1 reply

0 recast

2 reactions

frangio pfp

According to Hacker's Delight, it doesn't look like there's an arithmetic solution. It proposes using a rotating shift that we can emulate in the EVM by first duplicating the number to 64 bytes using MUL. This should be better than masking and shifting each byte separately. In principle this should cost 41 gas.

1 reply

0 recast

2 reactions

frangio pfp

There's an EIP for this: https://eips.ethereum.org/EIPS/eip-7377

2 replies

0 recast

5 reactions

frangio pfp

What are your concerns with IPFS?

1 reply

0 recast

0 reaction

frangio pfp

This looks good, but note that if the signature can itself be ERC-1271, you don't have a "recover" operation so you need to know what signer to verify against. I don't think that's your case though.

1 reply

0 recast

1 reaction

frangio pfp

General ERC-1271 signatures should be treated opaquely, so I think this would make more sense as a Farcaster-specific spec rather than a general purpose ERC.

1 reply

0 recast

1 reaction

frangio pfp

EIP-55 is a very clever abuse of hexadecimal notation.

0 reply

0 recast

2 reactions

frangio pfp

I feel a sudden urge to discuss EVM arcana

1 reply

0 recast

2 reactions

frangio pfp

Sign up below, I'll give a heads up that you're interested! https://www.openzeppelin.com/defender2-waitlist

1 reply

0 recast

0 reaction

frangio pfp

0 reply

0 recast

0 reaction

frangio pfp

Check out ERC-7201! It's a jargon-free version of diamond storage we put together for OpenZeppelin Contracts 5.0. https://eips.ethereum.org/EIPS/eip-7201

1 reply

0 recast

3 reactions

frangio pfp

Check out this Paradigm article: https://www.paradigm.xyz/2023/01/eth-rng

1 reply

0 recast

1 reaction

frangio pfp

There's even a video series! https://www.youtube.com/playlist?list=PLjQ9HCQMu_8xjOEM_vh5p26ODtr-mmGxO

1 reply

0 recast

5 reactions

frangio pfp

It seems to be folklore that LLVM is not a good fit to target the EVM. This is the best overview I could find: https://github.com/ewasm/design/blob/8ecee83f9ac58aa5f81b01498bc729789535bc29/comparison.md#llvm-ir

0 reply

0 recast

0 reaction

frangio pfp

That said new compilers should not be targetting EVM directly. We need compiler infrastructure like LLVM. I think Yul was supposed to be this but I don't think it has succeeded so far.

1 reply

0 recast

0 reaction

frangio pfp

Bootstrap the language by compiling to Solidity at first. Instruct users of the language to have the Solidity output audited. Gain confidence in the language and grow an ecosystem this way. Eventually develop an EVM backend and fuzz it against the Solidity backend. Pray.

1 reply

0 recast

4 reactions

frangio pfp

Have you found this approach to help with that? I always imagined the difficulty to provide feedback came from the fact that at the end you will have two pieces of bytecode, and if they don't match there isn't much you can say about the cause.

1 reply

0 recast

0 reaction

frangio pfp

I assume you don't support JSON input because one of the main goals is to match to a git commit? It would be useful to support it as it's a universal interface that all toolchains should be able to generate. Perhaps you can match the contents in the JSON file against the files in the repo.

1 reply

0 recast

1 reaction