You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
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
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.
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 😁
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.
The text was updated successfully, but these errors were encountered: