Submit design proposals for an onchain Diamond factory/generator that uses Compose

[mudgen]

Need design ideas and proposals for implementing a diamond factory/generator for this library, that can be used by people to generate diamonds that reuse the onchain facets of this library. All kinds of aspects need to be designed and discussed and planned, including security and safety mechanisms and command line tools and user interfaces.

For now please submit ideas and suggestions and proposals and plans and concerns, and any thing as comments to this issue.

[mudgen]

Diamond generator to look at: https://github.com/JoshdfG/Foundry-Factory-Diamond-Template

[cyotee]

How far would you want to take this factory process?

I made a Diamond factory with hooks for using packages.

https://github.com/cyotee/crane/blob/main/contracts/interfaces/IDiamondFactoryPackage.sol

To summarize, the interface is for contracts to act as packges for use with factory.

The factory defines a lifecycle that makes calls to a package to calculate a salt, process user arguments, initialize a new Diamond proxy, and process any post-deploy actions. It also inserts Diamond Loupe and ERC165 facets by default.

Diamond Cut inclusion is handled by this package, Where it allows for providing the encoded call for the initialization code.

My goal was to support all conceivable deployment scenarios, and standardize a lot of boilerplate logic. Trying to make it easy to deploy a Diamond by letting developers only worry about declaring their specific configuration.

I also included CREATE2 metadata exposure. That allows the factory to be idempotent by checking and confirming if an instance was already deployed, and then just return that address.

But it is likely a bit more opinionated them you might want.

If something similar is desirable to you, I could make a more streamlined and less opinionated version that conforms with your project directives.

[pellyadolfo]

I did something basic as a factory for my project a couple of years ago

https://github.com/Catallactic/catallactic-suite/blob/main/contracts/controller/CryptocommoditiesFactory.sol

Would be nice having a registry of facets per deployed chain.

[cyotee]

This factory should probably have an opinion about initialization best practice. And since the project wants to promote reuse of on-chain code, it should probably group Diamond Cuts by facets and the initialization call relevant to those facets; emitting several DiamondCut events to record the several initialization calls.

Something like

struct DiamondCut {
FacetCut[] facetCuts;
address initTarget;
bytes encodedInitArgs;
}

struct DiamondDeploymentArgs {
DiamondCut[] diamondCuts;
bytes32 optionalSalt;
}

function deployDiamond(
DiamondDeploymentArgs calldata args
) external returns (address diamond);

Then execute this pseudocode

for each DiamondCut process FacetCut[];
Delegatecall initTarget with encodedInitArgs;
emit DiamondCut event;

The Diamond proxy would be deployed with CREATE2/3 using a hash of the DiamondDeploymentArgs as the salt. That way the optionalSat can be defined to allow for deployments of duplicate proxies.

[cyotee]

Facet Registry could expose sets of facets, grouped by exposed ERC165 interface ID/s, and storage namespaces. If a facet exposes a subset of a ERC's functions, then it just uses the ERC165 interface ID produced from those functions. Might need to also declare the interface ID the subset is from, but distinct from the fully implemented IDs so there's no confusion.

[darkrain]

I stumbled upon this project by chance and am ready to fully participate because we're solving the same problem, except you're creating ready-made packages for my tool - https://github.com/EMVPack/core

I think I've already started solving this problem without knowing about your project. Only more comprehensively. I'm annoyed that our implementation updates are chaotic, and we're not taking advantage of reusing ready-made implementations.

I haven't gotten around to the diamond factory yet, but I created TransparentProxy because I already had a lot of experience with it, but I didn't have any experience with diamonds.

But as I see it now, each diamond is a separate package with a package type of implementation and a proxy type of diamond. Diamonds have dependencies on faces, and each face is also a separate package and is effectively used only by diamonds.

What this provides:

• A registry of edges stored on-chain, anyone can easily reuse them and build their own diamond.
• The semver versioning system provides a transparent lifecycle for all code and improves security during updates.
• The ability to create a more transparent audit, because we can approve a specific package with a deployed edge implementation and create a truly powerful trust system.

My goal:
I want application development in the EVM ecosystem to stop being intimidating for solo developers, so they can build their applications quickly, securely, and with minimal investment.

[mudgen]

What this provides:

• A registry of edges stored on-chain, anyone can easily reuse them and build their own diamond.
• The semver versioning system provides a transparent lifecycle for all code and improves security during updates.
• The ability to create a more transparent audit, because we can approve a specific package with a deployed edge implementation and create a truly powerful trust system.

That is correct!

My goal:
I want application development in the EVM ecosystem to stop being intimidating for solo developers, so they can build their applications quickly, securely, and with minimal investment.

Wonderful!

Let's work together and make this happen. I would be happy for our facets/diamonds/packages to integrate and work with your tooling or however we can best work together. Together we can do more.

[darkrain]

What this provides:

• A registry of edges stored on-chain, anyone can easily reuse them and build their own diamond.
• The semver versioning system provides a transparent lifecycle for all code and improves security during updates.
• The ability to create a more transparent audit, because we can approve a specific package with a deployed edge implementation and create a truly powerful trust system.

That is correct!

My goal:
I want application development in the EVM ecosystem to stop being intimidating for solo developers, so they can build their applications quickly, securely, and with minimal investment.

Wonderful!

Let's work together and make this happen. I would be happy for our facets/diamonds/packages to integrate and work with your tooling or however we can best work together. Together we can do more.

Okay, I'm ready to take on this task, implement the factory in my tool, create packages from all of ready facets (ERC173, ERC721, ERC20), and demonstrate how it works. What's the deadline for this task? I'm currently preparing for the release and will be working on other tasks for another 2-3 days.

[mudgen]

Sounds great. Deadline is as soon as you can. Keep in mind that the contracts in Compose are not production ready yet but can be used for development, proof of concept and testing etc.

[darkrain]

Sounds great. Deadline is as soon as you can. Keep in mind that the contracts in Compose are not production ready yet but can be used for development, proof of concept and testing etc.

Yes, i understand, my tool in same stage.

[mudgen]

I am converting this issue into a discussion. So let's use Github discussion functionality, to discuss!