[ICON] Week 4 ICONick Update
In our week 3 update, we talked about the tools we are using to deploy INS (ICONick Name Service) — T-bears — as well as the different scenarios we considered in designing the components of INS. This week, we are going to look into INS at a larger scale, on where INS stands in ICON blockchain, how it could interact with other layers within the infrastructure, and finally, how it can potentially affect the ICON ecosystem.
ICON Tech Stack
Below is the image of how ICON’s current tech stacks look like. Here, we will examine each layer and distinguish where INS stands.
(1) State layer is where user’s “state”, or user’s information and behavior, is stored. For ICON, Loopchain is where these data are stored, and gives users the ability to control their own state.
(2) Computation layer is where SCORE executes complicated calculations. It is an environment for smart contracts on ICON to be checked and managed, just like how EVM (Ethereum Virtual Machine) manages smart contract on Ethereum. When a transaction occurs on ICON, the logic designed in SCORE will determine its path that cannot be altered. Portal Network will be deploying INS (SCORE) on this layer that consists 3 major components.
With the combination of state layer and computation layer, many things could be implemented in the (3) component layer. INS for instance, consists 3 major components — registrar, registry and resolver (read Week 3 update). These components make sure that INS is operable and could meet the specific needs of each individual.
On the (4) Protocol Layer, we will be presenting our BNS (Blockchain Name Service) standards that can make the INS more efficient and applicable. With the state, computation and component layers behind the scene, protocol layer serve as a gateway for users and developers to interact with our INS standard.
In other words, users and developers can simplify the interaction with SCORE and its components by directly communicating with this protocol layer. Through the protocol layer, users can seamlessly control their INS, while developers can implement INS into the services they are building, which leads to real use cases in next two layers: (5) User Control Layer and (6) Application Layer.
User control layer is in charge of managing private keys to communicate with the state layer. INS empowers users to control, set up and manage their digital asset with an easier and readable text. This enables more use cases around INS at the application layer. For example, our Web Builder let users to create their own decentralized websites (DWebs) binded with an INS, and a further enhancement on our extension could be used to access these DWebs with ease at “yourwebsite.icon”.
INS can be implemented into many other applications on ICON platform, such as wallet that can resolve INS, dApp that utilize INS for users identity and many more. We believe that it is an essential components to provide a better environment for both technical and non-technical users.
Lastly, we are sharing our INS repo with the community. Feel free to create an issue for any suggestion or bugs. We value communities’ contribution so any feedback will be highly appreciated.
Thank you for reading.
Stay tuned by joining Portal Network’s Channels.
Social Media: Telegram | Reddit | Twitter | Facebook | Github |Websites & Products: Official Website | FORUM | MUMEI | KAIZEN |
