Replies: 15 comments 8 replies
-
|
Diamond generator to look at: https://github.com/JoshdfG/Foundry-Factory-Diamond-Template |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
I did something basic as a factory for my project a couple of years ago Would be nice having a registry of facets per deployed chain. |
Beta Was this translation helpful? Give feedback.
-
|
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 { struct DiamondDeploymentArgs { function deployDiamond( Then execute this pseudocode for each DiamondCut process FacetCut[]; 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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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:
My goal: |
Beta Was this translation helpful? Give feedback.
-
That is correct!
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
Yes, i understand, my tool in same stage. |
Beta Was this translation helpful? Give feedback.
-
|
I am converting this issue into a discussion. So let's use Github discussion functionality, to discuss! |
Beta Was this translation helpful? Give feedback.
-
|
Copying Discord messages here. not_cyotee — Yesterday at 19:31 I made a version of a Facet Registry. And considered there was no good solution to allowing public registration. If you let anyone register a Facet, then ethere's no way to know which are safe without an additional tagging process. But if you make a package for the Registry, then you can simply allow other devs to deploy their own Registry to declare their own Facets. And those Facets can alweays be promoted into other Registries if desired. Mikhail Ivantsov — Yesterday at 23:14 The package will be able to extend EVMPack's CLI. The audit functionality will also be wrapped in a separate package So, if i correct understand your case.
look at this architect like a linux, linux have paradigm one task=one program. In EVMPack i try to follow are same paradigm. not_cyotee — 08:43 And whom decides which is the current version? I think your Linux analogy breaks down. First, I run the kernal on my machine, so I control which kernal is available. And when I pick a distro, there's a specific, managed repo for that code. The repo inherits the level of trust I am willing to extend to the maintainer. Not just anyone can come along and upload kernal changes to the Ubuntu repo. — 08:52 — 08:56 not_cyotee — 09:12 Here is my factory. I removed my previous work on a Registry pending a reimplementation. My goal was to minimize the bytecode size being deployed and minimize duplication. The Factory itself defines a lifecycle based on frameworks like Spring and Hibernate. It also acts as a Facet for Diamond Lupe and ERC1655. Packages declare their configuration, that way the Diamond initialization logic remains consistent. Then the Package only has to worry about it's specific business logic initialization. Facet may optionally declare their interfaces and functions so Packages can reuse them. Otherwise, only the Package must make those declarations. I also followed the One Package = One Proxy model. https://github.com/cyotee/crane/blob/main/contracts/interfaces/IDiamondFactoryPackage.sol https://github.com/cyotee/crane/blob/main/contracts/interfaces/IFacet.sol And, so it doesn't get lost in the shuffle, my previous responses and reasons for eexpecting developers to deploy their own Registries. compose More then open to discussing the Registry point. But I will die on this hill after having spent a couple years mulling over this point. |
Beta Was this translation helpful? Give feedback.
-
Perhaps you simply misunderstood the architecture of the current registry, or I'm explaining it poorly. It's more likely the latter, as I don't have time for more extensive documentation right now. I don't see any motivation to deploy my EVMPack to everyone who wants it because it would lose a huge number of benefits. But if there's demand for this feature, I'll create a convenient cli for it; it's no problem. At this stage, the registry is completely devoid of any auditing systems, but no one is saying it won't be. Let's take a closer look at the lifecycle of an implementation-type package. (Remember, there's also a library type, where it's just source code.) Developer
struct Package {
address owner;
PackageType _type;
string name;
string meta;
}
struct Release {
string version;
string manifest;
}
struct Implementation {
ImplementationType implementationType;
address target;
string selector;
}We have a package owner, which is necessarily a release. In this case, a release is an implementation, so we tell the registry that here is the implementation address of the current release version. The manifest contains additional information: {
dependencies: releaseConfig.dependencies,
note: releaseNoteCid,
tarball: tarballCid,
source: sourceCid,
abi: abiCid,
}dependencies prevents you from loading the package if the registry doesn't contain the required dependencies. note - this is information about the release; it can be shown to whoever will use it. tarball - a project archive with contracts, artifacts, tests, etc. Yes, you could link to GitHub, but who trusts it? Further, to update the package, you must be either the owner or the maintainer. The registry will prevent you from overwriting an already loaded implementation, will prevent incorrectly generating a version, and will verify that you actually specified the contract address. Okay, we still don't have any package auditing, but this shouldn't be part of the registry from an architectural perspective. That means it will be a separate contract, and it can access the registry and have all the information needed to perform an audit. I see two approaches:
How will this work in our world? A package that wants to be trusted must provide a security deposit. The developer can deposit any amount themselves or pay a company that will cover the package with its security deposit after the audit. Users will see the amount of the package's insurance and decide whether to use it. The security deposit will be managed entirely by the DAO, meaning the deposit cannot be returned to the owner. In the event of an insured event, the deposit can be used to compensate for losses. The ratio of the assets managed by the package to the deposit can be displayed and a rating can be generated. It turns out that until an audit system is implemented, you can use the registry yourself, for convenience, to collect and reuse your own packages in different projects or packages you trust. Let's say a friend from another company also uses the registry and shows what packages they've created. Overall, at the current level, the registry has the same level of trust as GitHub. For example, if OZ indicates in their repository that they support the EVMPack registry and simply lists the package name, for example: contracts@oz, then using a package from the registry, you'll be reasonably confident that everything is ok (but not completely). You can deploy your own registry; that's not a problem, but if the main registry evolves, then:
To do more than just a registry, we need to create a DAO that will develop an ecosystem around the registry and act as a guarantor, but that's a completely different topic. |
Beta Was this translation helpful? Give feedback.
-
|
Got it, we're talking about different things. This is for linking to off-chain data. Yes, the Facet would be deployed, but you're not concerned with facilitating on-chain reuse. You're concerned with publishing off-chain data announcements, and linking to the deployed code. None of that data is expected to be used on-chain. But still, what stops malicious actors deploying malicious Facets, and adding them to registry? If the Registry is quality agnostic, is it really providing any value for publishing this data on-chain.
Why? What's the point of publishing this information for private consumption? You don't need to make it available on-chain if you're the only expected to use it.
Huge hurdle for new devs. Kind of a deal breaker for me. Who's in charge of this deposit? Who decides when it would be paid out, and to whom? Who decides how much the deposit needs to be, and how do you ensure the deposit grows with adoption? Is the dev on the hook if their code gains adoption, and suddenly it's responsible for a billion dollars or more? Do you know anything about insurance, liability, and indemnification? Why not just use Kleros for the security deposit? Even trying to take this on opens you up to extensive liability. Overall, I think you're trying to solve a problem better solved by integrating existing services. And it's beyond the scope of what a framework project should be doing. I know I don't want to be involved in trying to run an insurance service. And all of that would be resolved by just expecting devs and orgs to have their own registries for the code they choose to sanction for use. I like the process, it's a problem to solve, there are several existing attempts to solve this. So it's a well-identified problem to solve. Looks like we've been solving different concerns. My factory is about making is easier to deploy consistent proxies. So both could work together. But rankly, why not just use dsuite and the dpack standard? https://bafybeibtqqutpheuvcvpxdb2jafg6srguy3nlgzmu5q3i5yvexlshsz5pu.ipfs.w3s.link/dsuite.html If you want git features, why not use Radicle? General point for blockchain development. Why is everyone trying to centralize services on a decentralized platform? I see no benefit having a single registry, and a lot of problems from trying. Problems not worth taking on, because a project like this will never have the resources to properly manage this. No one could manage indemnification for even a fraction of deployed code. |
Beta Was this translation helpful? Give feedback.
-
|
I find it convenient to use the registry for my other project because I need clear contract lifecycle management after I've deployed everything to mainnet. It wasn't originally created as a standalone project; it just became crowded, and it would be nice to have someone else maintain it besides me.
What prevents an attacker from uploading malicious code to GitHub or NPM? With this registry, I can at least be sure that no one will replace an existing package that I've verified myself.
There's no obstacle. The registry doesn't require any collateral; publish as much as you want. A separate contract that handles auditing takes collateral and has nothing to do with the registry. EVMPack can then integrate it into the UI and show that the package has been audited, and without verification, simply warn the user that the package hasn't passed the audit, but you can personally verify it. The question of how to build an audit system is beyond the scope of this discussion; we can continue this in the Discord privately. The last thing I'll add is that someone must be responsible for the code that was deployed. Even if the auditing company has a deposit or $2 million in insurance to cover its clients, it will still be more responsible in its auditing, and the client will be able to choose a reputable auditing company. There are now a huge number of companies that conduct audits, and I'm tired of checking them all.
The ready-made solutions you provided are outdated and missing a lot. |
Beta Was this translation helpful? Give feedback.
-
|
Nothing, but Github and NPM isn't expecting a security deposit.
That's only a problem when you try to centralize this service.
But you said a deposit is required to become trusted. Why have a "trusted" status in the first place?
I agree, that's why I dislike having a centralized registry.
Missing what, exactly? What problem do you think you're solving that existing solutions don't solve? |
Beta Was this translation helpful? Give feedback.
-
|
I think 3 of them are valid use cases:
Whereas I think Compose can help a lot developers/users in terms of dev+CI/CD, I do think is the main target of the project because there is probably also a gas penalty that many dev teams would not want to pay. And focusing in this target could be the wrong goal. I think the main benefit of Compose (or a Compose spinoff, is fine) is creating a point of trust for retail investors in terms of security and transparency, regarding all the contract lifecycle (deployment, execution, upgrades..). This is what is failing today in crypto IMHO and retail investors have mostly run away. I see Compose as the oppportunity to bring them back. I also think, that several versions of every facet should coexist in the chain to allow adopters upgrade or not. In my understanding adopters should be able to involve investors somehow in the upgrade workflow (some kind of governance) and this is IMHO a feature to (be discussed and) include in Compose. |
Beta Was this translation helpful? Give feedback.
-
|
@pellyadolfo Why not split the difference? Have a Compose canonical Registry of Facets, as I concur with your point about presenting a reliable source for quality code. But make sure the Factory process can handle using other Registries. That allows for anyone to publish compatible code. And allows for other organizations to take on the burden of validating code. For example, promote Auditors to maintain their own Registries of Facet code they've audited as safe. Basically, anyone could be a publisher and cross-promote by deploying their own Registry. Just make sure a Registry can add any Facet the maintainer wishes. That also avoids Compose having to shift from primarily development to reviewing code if contributions grow. |
Beta Was this translation helpful? Give feedback.
-
|
Well, valid point. When you say their own registries you mean we will have ERC-20 by auditor A and ERC-20 by Auditor B, no matter if is exposed as a different registry or as an account of the same registry. If Compose succeeds (hopefully), it will probably happen, auditors will create their own versions of the existing facets. The problem is that it will translate confusion to the investor as the previous model is just being moved onchain. Well, this is a Nick's strategic decision. Who do you want to be your users, auditors or projects? Sounds that the best approach, at the moment, with only a few new projects on market, is starting with projects, learn from it and after, if the model consolidates, scale to auditors. |
Beta Was this translation helpful? Give feedback.
-
|
Well, with that public mandate, I will now crusade for maintained registries. |
Beta Was this translation helpful? Give feedback.
-
|
I do not see auditors as users at the short term. If you are imposing a new coding standard, you need to proof your coding standard in the market before expecting auditors to accept it. Think that they do not have people trained in building facets. At the long term? Well, who knows, maybe. My opinion. |
Beta Was this translation helpful? Give feedback.
-
|
I wasn't expecting auditors to adopt this. That was just one hypothetical of the outer limits of adoption. Beyond developers using it. And even then, I would expect a Registry to be entirely optional. I think the factory should just accept the Diamond Cut configuration. It wouldn't need anything else. |
Beta Was this translation helpful? Give feedback.
-
|
I've been using a modified version of https://github.com/forgenie/diamond-foundry and it's worked well. I modified the diamond factory to use EIP-7955 for deterministic addresses on all EVM networks. The generic diamond factory simply emits
Since it's from a factory contract, correct? I create purpose-built factories that emit events (like I also use a Facet Registry, as supported by the forgenie diamond foundry project. I've found it useful to be able to give human-readable names to facets registered in the Facet Registry, as well as semantic versioning. Assuming a registry is even desirable, since the facet addresses are unique based on bytecode, salt (which should be the human-readable name in SNAKE_CASE) and version number, we can have a global facet registry. I wouldn't overcomplicate things, keeping it global makes it easier for developers to adopt, but I do see potential in unique registries etc., I just haven't thought it all the way through. Re: safety of registered facets, the registry could show who registered the facet (address) and rely on external identifiers like *.eth domain names or EAS attestations IMO. This way we can also filter registered facets by registrants for curation. Facet registry should be deployed using the EIP-7955 method so it has the same address across networks. Off-topic but kind of related: one of the biggest pain points for constructing diamonds via the factory is ensuring function selectors are all correct. Using AI-powered workflows like Cursor are super prone to hallucinating selectors, so having tools to ensure generation of selectors from contracts/artifacts is super helpful to have. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions