Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement GRC165 #2086

Open
DIGIX666 opened this issue May 13, 2024 · 1 comment
Open

Implement GRC165 #2086

DIGIX666 opened this issue May 13, 2024 · 1 comment
Labels
❓ question Questions about Gno

Comments

@DIGIX666
Copy link
Contributor

Question

Hi, I would like to know if there is a desire in Gno to have a GRC165, because from what I have read on https://eips.ethereum.org/EIPS/eip-165, it would be cool to have it, but I am not sure if it is very relevant in the long term.

I'm asking because with @gnolang/24-zone01-1 we are working on creating a p/timelock / source.

@DIGIX666 DIGIX666 changed the title GRC165 implement grc165 May 15, 2024
@leohhhn leohhhn changed the title implement grc165 Implement GRC165 May 15, 2024
@leohhhn leohhhn added the ❓ question Questions about Gno label May 15, 2024
@DIGIX666
Copy link
Contributor Author

After some research, I don't think there is an interest in implementing ERC165 on Gno.

The reason is that ERC165 was created on Solidity because, as explained by OpenZeppelin: "Ethereum contracts do not have a native concept of an interface, so applications typically need to ensure they are not making incorrect calls. For trusted setups, this is not an issue, but often it is necessary to interact with unknown and untrusted third-party addresses. There might not even be any direct calls to them! (For example, ERC20 tokens can be sent to a contract that has no way to transfer them out, locking them forever). In these cases, a contract declaring its interface can be very useful to avoid errors."

However, in Gno we don't have this issue:

  1. Unlike Solidity, where the source code of smart contracts is compiled into bytecode before being deployed on the blockchain, Gno maintains the source code as is. This means that everyone can read and verify the source code directly on the blockchain, making interface verification much simpler and more straightforward

  2. Gno, which is based on Go, has static type checks and a robust interface system. This allows for clear definition of interfaces and implementations, and the Go compiler checks that types and interfaces are correctly implemented.

  3. Gno requires the separation of packages and realms. This facilitates modularity, the use of standardised interfaces, code reuse, and interoperability between smart contracts. It makes development more structured and maintainable while providing the type and security guarantees that Go natively offers.

Here is my opinion on the ERC165 topic based on my research. Feel free to provide feedback if you wish or correct me on the information I provided about Gno 😁

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
❓ question Questions about Gno
Projects
None yet
Development

No branches or pull requests

2 participants