[WIP] Code Jar Improvements, Deploy with Code Jar, and Verification #127

hayesgm · 2023-12-08T21:19:33Z

This patch improves CodeJar to deploy a new contract CodeJarStub instead of building the EVM opcodes by hand. This is because we can use return() yul-opcode in constructors to build custom code (weird, right!?). From this, we also build a way of deploying contracts using CodeJar (that is: content-addressible contracts-- the deploy address is based on the actual opcodes of the contract you are deploying). Further, we work on verify functionality for these contracts, which works if (and right now, only if) the deployed contract doesn't use const immutables. There are reasons this could break otherwise, but for simple contracts, it works.

This patch improves CodeJar to deploy a new contract `CodeJarStub` instead of building the EVM opcodes by hand. This is because we can use `return()` yul-opcode in constructors to build custom code (weird, right!?). From this, we also build a way of deploying contracts using CodeJar (that is: content-addressible contracts-- the deploy address is based on the actual opcodes of the contract you are deploying). Further, we work on `verify` functionality for these contracts, which works if (and right now, only if) the deployed contract doesn't use `const immutable`s. There are reasons this could break otherwise, but for simple contracts, it works.

hayesgm · 2023-12-08T23:28:56Z

quark-core/src/Simple.sol

@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: BSD-3-Clause


This whole contract can be removed before we merge.

hayesgm · 2023-12-08T23:29:18Z

quark-core/src/CodeJar.sol

        return address(
-            uint160(uint256(keccak256(abi.encodePacked(bytes1(0xff), address(this), uint256(0), keccak256(initCode)))))
+            uint160(uint256(keccak256(abi.encodePacked(bytes1(0xff), address(this), uint256(0), keccak256(abi.encodePacked(type(CodeJarStub).creationCode, abi.encode(code)))))))


Note the abi.encode() here is encoding as it's actual type bytes and thus prepending length, etc.

It should be 0x0000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000{len}{...bytes} I believe

hayesgm · 2023-12-08T23:30:18Z

quark-core/src/CodeJarStub.sol

+contract CodeJarStub {
+    constructor(bytes memory code) {
+        assembly {
+            return(add(code, 0x20), mload(code))


Funny that this works. It doesn't work as well with const immutables in the contract, though.

hayesgm · 2023-12-08T23:30:49Z

script/DeployQuarkWalletFactory.s.sol


        vm.startBroadcast(deployer);

        console.log("=============================================================");
        console.log("Deploying QuarkWalletFactory");

-        quarkWalletFactory = new QuarkWalletFactory();
+        quarkWalletFactory = QuarkWalletFactory(deploy(type(QuarkWalletFactory).creationCode, hex"", deployerPk));


This is just a test to see if we could deploy this way. We probably don't want to...

hayesgm · 2023-12-08T23:32:03Z

script/verify-with-code-jar.sh

+contract_src="./src/$contract.sol"
+contract_deployed_src="./src/${contract_deployed}.sol"
+
+cat "$contract_src" \


Verify is a little weird for a fun reason. It makes a copy of your contract (e.g. SimpleDeployed.sol), changes the constructor to match CodeJarStub, compiles that new contract, and verifies that contract at the address. It's pretty nifty that it kinda works. Note: we don't use solc directly here to compile since we want to mirror your foundry settings.

hayesgm · 2023-12-08T23:32:23Z

script/verify-with-code-jar.sh

+constructor_args=`cast abi-encode "cons(bytes)" $deployed_code`
+
+contract_src="./src/$contract.sol"
+contract_deployed_src="./src/${contract_deployed}.sol"


This is obviously a bit too specific to using ./src etc, though this stuff is a little hacky all around anyway

hayesgm · 2023-12-08T23:32:37Z

test/quark-core/CodeJar.t.sol

@@ -95,6 +95,8 @@ contract CodeJarTest is Test {
            hex"00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff";
        scripts[7] =
            hex"00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff11";
+        scripts[8] =


wanted something really big to see that it didn't change nothing

fluffywaffles

honestly, I found the previous version more intuitive. I guess solidity understands this version well enough that we can, more-or-less, have verification?

fluffywaffles · 2023-12-12T19:28:33Z

script/CodeJarDeployer.s.sol

+// ETHERSCAN_KEY
+
+contract CodeJarDeployer is Script {
+    address constant DEFAULT_CODE_JAR = address(0xcA85333B65E86d114e2bd5b4aE23Fe6E6a3Ae8e3);


how exactly is this determined? is this a goerli codejar address? 🤔

Looks like it. But the plan is to have this be the same address on each chain

fluffywaffles · 2023-12-12T19:34:46Z

script/deploy-with-code-jar.sh

+  elif [[ ${constructor_abi} =~ ^\([[:alnum:]_,]+\)$ ]]; then
+    constructor_abi="cons$constructor_abi"
+  elif [[ ${constructor_abi} =~ ^[[:alnum:]_,]+$ ]]; then
+    constructor_abi="cons($constructor_abi)"


is this how the solidity constructor is invoked, using a selector for the string cons? I really cannot tell if this is an implied default, which assumes that you've implemented a method named cons, or if it will invoke a constructor() {..} as defined in solidity.

weirdly cast abi-encode both requires and ignores it.

fluffywaffles

I think we need to clearly document the "when" and "why" of codejar deploys, because I am still unclear on whether the primary benefit of deterministic addresses (that is, dependent upon the address of codejar itself) is worth it.

For Quark scripts, I think "yes," since the refactors allow us to verify codejar-deployed scripts. That's a clear win.

For everything else, although we keep talking about how it would be cool to deploy with codejar, the answer feels like "no" to me.

If we could make the entire constellation of Quark contracts content-addressible, it would feel like more of a win: codejar would be the deployer, the manifest for finding other contracts, the entrypoint to everything. However, if even one contract is not content-addressible, it's actually harder to find things. Today, all you need to know is the factory address, and everything else can be derived from there. If half of everything is codejar-derived, and the rest is factory-derived, it's just annoying.

kevincheng96

Interesting approach 🙌

Have you tried running the deploy script with constructor args?

kevincheng96 · 2023-12-12T21:04:48Z

quark-core/src/CodeJar.sol

-            assembly {
-                codeCreateAddress := create2(0, add(initCode, 32), initCodeLen, 0)
-            }
+            CodeJarStub codeCreateAddress = new CodeJarStub{salt: 0}(code);


nit: Can remove the address suffix since this isn't an address. One suggestion is to name this createdContract.

kevincheng96 · 2023-12-12T21:05:23Z

quark-core/src/CodeJar.sol

     * @dev Returns the create2 address based on the given initCode
     * @return The create2 address based on running the initCode constructor


Comments need to be updated

kevincheng96 · 2023-12-12T21:15:37Z

quark-core/src/CodeJar.sol

        );
    }
 }
+


nit: extra line

kevincheng96 · 2023-12-12T21:16:22Z

script/CodeJarDeployer.s.sol

+// ETHERSCAN_KEY
+
+contract CodeJarDeployer is Script {
+    address constant DEFAULT_CODE_JAR = address(0xcA85333B65E86d114e2bd5b4aE23Fe6E6a3Ae8e3);


Looks like it. But the plan is to have this be the same address on each chain

kevincheng96 · 2023-12-12T21:21:49Z

script/CodeJarDeployer.s.sol

+        }
+
+        // TODO: Consider metadata and verification
+        bytes memory deployedCodeWithMetadata = abi.encodePacked(deployedCode, hex"");


The hex"" is reserved for the metadata? Are there restrictions on what it can be?

kevincheng96 · 2023-12-12T21:22:48Z

script/CodeJarDeployer.s.sol

+            codeJar = CodeJar(codeJarAddr);
+        }
+
+        address initCodeAddr = codeJar.saveCode(abi.encodePacked(contractCode, constructorArgs));


This patch adds `det`, which is a proxy that always signs with the same exact signature. This allows for deterministic deployment addresses since it's a variety of content-addressable signatures. See the README.md in `det/` for more details. Note: I can't get it to work right now, but it... should... work? Like it's accepted to the mempool _then ignored_ which might indicate that the signature is not, in fact, valid, but looks valid to EthersJS and Infura.

hayesgm · 2023-12-14T21:19:24Z

Closing in lieu of #137, #138 and #139

hayesgm commented Dec 8, 2023

View reviewed changes

fluffywaffles reviewed Dec 12, 2023

View reviewed changes

kevincheng96 reviewed Dec 12, 2023

View reviewed changes

hayesgm closed this Dec 14, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[WIP] Code Jar Improvements, Deploy with Code Jar, and Verification #127

[WIP] Code Jar Improvements, Deploy with Code Jar, and Verification #127

hayesgm commented Dec 8, 2023

hayesgm Dec 8, 2023

hayesgm Dec 8, 2023

hayesgm Dec 8, 2023

hayesgm Dec 8, 2023

hayesgm Dec 8, 2023

hayesgm Dec 8, 2023

hayesgm Dec 8, 2023

hayesgm Dec 8, 2023

fluffywaffles left a comment

fluffywaffles Dec 12, 2023

kevincheng96 Dec 12, 2023

fluffywaffles Dec 12, 2023

hayesgm Dec 14, 2023

fluffywaffles left a comment •

edited

Loading

kevincheng96 left a comment •

edited

Loading

kevincheng96 Dec 12, 2023

kevincheng96 Dec 12, 2023

kevincheng96 Dec 12, 2023

kevincheng96 Dec 12, 2023

kevincheng96 Dec 12, 2023

kevincheng96 Dec 12, 2023

hayesgm commented Dec 14, 2023

		* @dev Returns the create2 address based on the given initCode
		* @return The create2 address based on running the initCode constructor

[WIP] Code Jar Improvements, Deploy with Code Jar, and Verification #127

[WIP] Code Jar Improvements, Deploy with Code Jar, and Verification #127

Conversation

hayesgm commented Dec 8, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fluffywaffles left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fluffywaffles left a comment • edited Loading

Choose a reason for hiding this comment

kevincheng96 left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hayesgm commented Dec 14, 2023

fluffywaffles left a comment •

edited

Loading

kevincheng96 left a comment •

edited

Loading