frangio pfp

frangio

@frangio

109 Following
152 Followers
frangio pfp
frangio
@frangio
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
frangio
@frangio
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
frangio
@frangio
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
frangio
@frangio
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
frangio
@frangio
EIP-55 is a very clever abuse of hexadecimal notation.
0 reply
0 recast
2 reactions
frangio pfp
frangio
@frangio
I feel a sudden urge to discuss EVM arcana
1 reply
0 recast
2 reactions
frangio pfp
frangio
@frangio
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
frangio
@frangio
Check out this Paradigm article: https://www.paradigm.xyz/2023/01/eth-rng
1 reply
0 recast
1 reaction
frangio pfp
frangio
@frangio
There's even a video series! https://www.youtube.com/playlist?list=PLjQ9HCQMu_8xjOEM_vh5p26ODtr-mmGxO
1 reply
0 recast
5 reactions
frangio pfp
frangio
@frangio
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
frangio
@frangio
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
frangio
@frangio
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
frangio
@frangio
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
frangio
@frangio
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
frangio pfp
frangio
@frangio
Internal calls are not affected by L1 DA costs so it doesn't necessarily make sense to design the whole interface for optimal calldata use. Add a calldata-optimized interface as a secondary set of functions that invoke unoptimized functions. By decoupling this way you don't have to rewrite everything when costs change.
2 replies
0 recast
5 reactions
frangio pfp
frangio
@frangio
Hi @timdaub.eth!
0 reply
0 recast
0 reaction