We could and should use a very thin contract as in proxy.sol so save on contract creation costs.
Right now, creating a manual rock-paper-scissors contract costs upward of 6e5 GAS — and though our compiler could make it smaller by a factor two or so by being more clever than solidity, the cost would still scale linearly with contract complexity, until we reach the 8e6 GAS limit per block. It's also a noticeable transaction cost to use our system.
I propose we use a very thin contract that just passes arguments through to the "factory" contract. As seen in the manual assembly code above, it's just 42 bytes and could lead to a flat-rate contract-creation cost under 1e5 GAS. The downside is that all GAS costs to interact with the contract increase by +1.6% (+1/63). Thus, this strategy is perfect for use with regular short-lived contracts with few interactions, but not for long-running contracts with regular interactions.
Now, most "regular" contracts are exactly that. Indeed, our model for a contract, similar to the State Channel model, is that people sign the contract and deposit collateral, people do everything offline, then people sign off a release form to get their collateral back (possibly with some transfers). Or if some interactions happen on-chain, there are few of them (as in the rock-paper-scissors example).
For long-running side-chain contracts, at least the everyday transactions in their happy path should be directly supported without a delegatecall. Unhappy paths can and probably should use a library contract with delegatecall, to save on cost to honest users during contract creation, while punishing dishonest users with this 1.6% tax during dispute resolution.
We could and should use a very thin contract as in proxy.sol so save on contract creation costs.
Right now, creating a manual rock-paper-scissors contract costs upward of 6e5 GAS — and though our compiler could make it smaller by a factor two or so by being more clever than solidity, the cost would still scale linearly with contract complexity, until we reach the 8e6 GAS limit per block. It's also a noticeable transaction cost to use our system.
I propose we use a very thin contract that just passes arguments through to the "factory" contract. As seen in the manual assembly code above, it's just 42 bytes and could lead to a flat-rate contract-creation cost under 1e5 GAS. The downside is that all GAS costs to interact with the contract increase by +1.6% (+1/63). Thus, this strategy is perfect for use with regular short-lived contracts with few interactions, but not for long-running contracts with regular interactions.
Now, most "regular" contracts are exactly that. Indeed, our model for a contract, similar to the State Channel model, is that people sign the contract and deposit collateral, people do everything offline, then people sign off a release form to get their collateral back (possibly with some transfers). Or if some interactions happen on-chain, there are few of them (as in the rock-paper-scissors example).
For long-running side-chain contracts, at least the everyday transactions in their happy path should be directly supported without a delegatecall. Unhappy paths can and probably should use a library contract with delegatecall, to save on cost to honest users during contract creation, while punishing dishonest users with this 1.6% tax during dispute resolution.