0xNelliI built an Onchain App: Front-end - Part 1
The code for the first stage of development explored in this article can be found here. Please use this to provide additional context in the event that any parts of this article are unclear. Additionally, if aspects of this article are unclear or do not follow best practices please let me on 𝕏.Project SetupSvelteKit InitialisationAs aforementioned in the previous article, I am using SvelteKit to build out my frontend. It is important to note that while Svelte recently announced the release o...
0xNelliTransparent Proxies & Upgradeability
The Goal of the Proxy PatternSmart contracts are immutable, therefore it is not possible to change the logic of a smart contract once it has been deployed. However, the ability to update code is often vital, whether to add new features or to patch critical bugs and defects. This is what the proxy pattern offers to developers, a means of updating code by introducing upgradeability to smart contracts. Upgradeability is achieved by separating storage and logic. A proxy contract contains the stat...
Fledging Security Researcher | Software Engineer | Onchain Enthusiast
0xNelliI built an Onchain App: Front-end - Part 1
The code for the first stage of development explored in this article can be found here. Please use this to provide additional context in the event that any parts of this article are unclear. Additionally, if aspects of this article are unclear or do not follow best practices please let me on 𝕏.Project SetupSvelteKit InitialisationAs aforementioned in the previous article, I am using SvelteKit to build out my frontend. It is important to note that while Svelte recently announced the release o...
0xNelliTransparent Proxies & Upgradeability
The Goal of the Proxy PatternSmart contracts are immutable, therefore it is not possible to change the logic of a smart contract once it has been deployed. However, the ability to update code is often vital, whether to add new features or to patch critical bugs and defects. This is what the proxy pattern offers to developers, a means of updating code by introducing upgradeability to smart contracts. Upgradeability is achieved by separating storage and logic. A proxy contract contains the stat...
Fledging Security Researcher | Software Engineer | Onchain Enthusiast
Subscribe to 0xNelli
Subscribe to 0xNelli
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
ERC-165 is an interface identification mechanism that enhances compossibility as contracts can determine whether a contract supports an interface at compile time.
Prior to ERC-165, there was no mechanism to check whether a contract supported a specific interface, such as ERC-20. Therefore, there was no way of verifying whether a contract could accept tokens or tokens sent to a contract would be ‘stuck’ and effectively lost.
ERC-165 introduces a standardized function to declare support for specific interfaces within a given contract. Other contracts can call this function to verify whether a certain interface is supported.
function supportsInteface(bytes4 interfaceId) external view returns (bool);
In the wild you may have observed something like this:
function supportsInterface(bytes4 interfaceId) public view override(ERC1155, AccessControl) returns (bool) {
return super.supportsInterface(interfaceId);
}
This is required when a contract inherits multiple instances of supportsInterface for different interface standards. In the example above, the contract inherits from both ERC-1155 and Access Control. The contract must override supportsInterface function and uses the super keyword to specify that the contract's own supportsInteface function should combine the from both interfaces. This way the supportsInterface function will return true for both queries with ERC-1155 and Access Control.
ERC-165 is an interface identification mechanism that enhances compossibility as contracts can determine whether a contract supports an interface at compile time.
Prior to ERC-165, there was no mechanism to check whether a contract supported a specific interface, such as ERC-20. Therefore, there was no way of verifying whether a contract could accept tokens or tokens sent to a contract would be ‘stuck’ and effectively lost.
ERC-165 introduces a standardized function to declare support for specific interfaces within a given contract. Other contracts can call this function to verify whether a certain interface is supported.
function supportsInteface(bytes4 interfaceId) external view returns (bool);
In the wild you may have observed something like this:
function supportsInterface(bytes4 interfaceId) public view override(ERC1155, AccessControl) returns (bool) {
return super.supportsInterface(interfaceId);
}
This is required when a contract inherits multiple instances of supportsInterface for different interface standards. In the example above, the contract inherits from both ERC-1155 and Access Control. The contract must override supportsInterface function and uses the super keyword to specify that the contract's own supportsInteface function should combine the from both interfaces. This way the supportsInterface function will return true for both queries with ERC-1155 and Access Control.
No activity yet