Blueprint support

Overview

There are several ways to support so-called “blueprints” or factory-style contracts in different ecosystems. For example, ape-starknet has encode_contract_blueprint which takes advantage of a native StarkNet feature that allows encoding a contract type into a special chain-specific contract cache that new copies can be deployed from. In EVM ecosystems, a standard EIP-5202 is being developed that generalizes blueprint-style deployments (e.g. a contract that only supports codecopy for CREATE/CREATE2 deployments). In the past, there have been several other proxy/non-proxy implementations of similar ideas, but this standard has real promise for the ecosystem.

For ape, we should add a method that supports encoding a transaction which initializes a blueprint type on-chain for further use when linking code for making on-chain deployments.

Specification

class EcosystemAPI(...):
    ...

    def encode_contract_blueprint(self, contract: ContractType, *args, **kwargs) -> TransactionAPI:
        # doc string here...

class AccountAPI(...):
    ...
    def declare(self, contract_container: ContractContainer) -> ReceiptAPI:
        # Implement this

Dependencies

no dependencies

[fubuloubu]

Starknet accounts do have the additional declare() method, which is part of their spec and so it makes sense.

I think this might get more into the higher level API of how users might interface with this method

AccountAPI.declare(ContractContainer) -> ReceiptAPI is the higher level API for how we create blueprints. For EVM, this would craft an EIP-5202 style deployment, and then using receipt.contract_address as an ABI argument for any method/deployment that might want to reference the blueprint (this is typical of how this is used, as a template address). For StarkNet, there is a different flow where you would craft a “Contract Class Declaration” transaction type, and then the receipt would have receipt.class_hash available for you to use

[unparalleled-js]

Yes, I think this part for sure makes sense. This is the part that both ecosystems share in common anyway. The rest is normal Ape stuff anyway imo, (e.g. deploying factory contracts of some sort and using the result from sending the encoded-blueprint transaction), and that differs from ecosystem-to-ecosystem and even project-to-project. We can create some material in Ape academy show-casing all of this excited stirs.

Starknet accounts do have the additional declare() method, which is part of their spec and so it makes sense. Does anything like that in Ethereum make sense to have?