Describe the bug Docs say that deriving from AbstractPortal is "highly encouraged", which is != "required". PortalRegistry actually requires the portal to implement AbstractPortal interface to register.
To Reproduce Steps to reproduce the behavior:
- Create a contract that doesn't inherit from
AbstractPortal and provides a trivial IERC165 implementation:
function supportsInterface(
bytes4 interfaceID
) public pure virtual override returns (bool) {
return
interfaceID == type(IPortal).interfaceId ||
interfaceID == type(IERC165).interfaceId;
}
- Try registering a contract that contract with
PortalRegistry.
- Get the
PortalInvalid(); custom error revert.
Expected behavior Registration should work. AbstractPortal should not actually be required. We don't need or want 90% of it. The IPortal should express the interfaces we actually have to implement. There should be no assumption that all portals are derived from AbstractPortal, but requiring an interface implemetnation is fine.
If we are forced to use AbstractPortal we will stub all the functions that we don't want with reverts - and nobody wants that.
Also, we'd like to have a library (instead of an abstract contract) that would provide the functionality we like, without forcing a specific interface.
For now, we'll lie about implementing AbstractPortal in our IERC165's supportsInterface implementation.
Screenshots Nope.
Additional context We are building a portal that would be easy to use - without the need for passing any attestation payloads as input (we have the msg.sender already and that's all we need to generate everything on the fly).
The code in question:
|
// Check if portal has implemented AbstractPortal |
|
if (!ERC165CheckerUpgradeable.supportsInterface(id, type(IPortal).interfaceId)) revert PortalInvalid(); |
Describe the bug Docs say that deriving from
AbstractPortalis "highly encouraged", which is != "required".PortalRegistryactually requires the portal to implementAbstractPortalinterface to register.To Reproduce Steps to reproduce the behavior:
AbstractPortaland provides a trivialIERC165implementation:PortalRegistry.PortalInvalid();custom error revert.Expected behavior Registration should work.
AbstractPortalshould not actually be required. We don't need or want 90% of it. TheIPortalshould express the interfaces we actually have to implement. There should be no assumption that all portals are derived fromAbstractPortal, but requiring an interface implemetnation is fine.If we are forced to use
AbstractPortalwe will stub all the functions that we don't want withreverts - and nobody wants that.Also, we'd like to have a library (instead of an abstract contract) that would provide the functionality we like, without forcing a specific interface.
For now, we'll lie about implementing
AbstractPortalin ourIERC165'ssupportsInterfaceimplementation.Screenshots Nope.
Additional context We are building a portal that would be easy to use - without the need for passing any attestation payloads as input (we have the
msg.senderalready and that's all we need to generate everything on the fly).The code in question:
linea-attestation-registry/contracts/src/PortalRegistry.sol
Lines 164 to 165 in 397541e