For the last couple years I have kept my attention away from the crypto space, to avoid the toxicity that can come with it.
- Rather than collective/shared progress, cryptocurrency politics forced people to pick sides in an unwinnable war.
- The stress of holding money 'under your mattress' with no guarantee that it will be safe, especially from user error.
- 'Crypto bros' talking up coins that will 'moon' for no reason other than making money off of followers.
I needed to get out of the space for my own peace of mind. Now I'm back and I'm glad to see the innovation everywhere in the crypto-space. Then I ran across something called ICP.
What is it? (simplified)
The Internet Computer Protocol (ICP) is a (potential) alternative to cloud providers (like AWS and Azure) but built on blockchain. Rather than being hosted on centralized servers, applications can be deployed to a few nodes (servers) around the world.
Then the application is run simultaneously on each node and then the all nodes' results are cryptographically compared and validated. The validation requires the majority of the nodes to have the same result. This prevents bad actors from manipulating the application's processes.
This is where the ICP blockchain comes in. It determines a consensus for the valid result. Unlike other blockchains, nodes are run by providers that meet certain hardware requirements and approved by the community through the Network Nervous System (NNS, explained below) and are approved by the community.
No, you probably can't. And this is by the protocol's design.
Instead of getting a 'vote' by running a non-ICP blockchain node, control is given to users who are holding ICP tokens for 6+ months. Those users can vote through the Network Nervous System (NNS) on any and all proposals. These votes (and again, unlike other blockchains) execute in the NNS meaning it can be community governed and upgrade itself or anything in the ICP network.
This node provider method also avoids the common issue with other 'decentralized' blockchains, where nodes are often run on AWS or in large mining facilities. Every blockchain has their pros and cons but I'm optimistic about the ICP 'node provider' way of thought. Even if we want everyone to run their own hardware and be completely distributed, it's not going to work anytime soon because of humans. Humans don't want to manage something like that unless they are an enthusiast. The technology has to change first.
- Security and Management
- Developers can focus on their code rather than everything connected to it.
- All networking and hardware problems are delegated to the protocol or the node providers.
- No need for OAuth providers or email addresses. ICP supports the ability to specify and prove identity of users and applications. All that is needed is an [Internet Identity].(https://smartcontracts.org/docs/current/tokenomics/identity-auth/auth-how-to/)
- Common API language
- REST APIs are an afterthought built on years of web development. This has lead to headaches like dealing with authentication, finding and writing API docs, and handling a service's unique flavor of REST implementation.
- ICP has a single transparent and easy-to-use API. All a developer has to do is create an application with methods. Those methods are then publicly transparent and accessible.
- Smart contracts are mutable by default
- Other blockchains can't be updated, so workarounds are needed. But ICP developers can update code at any time
- It's slower than Web 2.0
- Though but much faster than other blockchain protocols
- Lack of Ecosystem Maturity
- Some parts are undeveloped or too centralized, but will get better over time
- Smart contracts are mutable by default (double edged sword)
- Code can change at any time, so the rules can unknowingly change on users
Here is a brief explainer video from the creators of ICP.
As a web developer, I finally feel like I can use my skills and contribute to the Web 3.0 movement. Smart contracts are game changing because it allows public databases and transparent validation of data, but its hard to develop with. I see the ICP helping with a lot of their pain points:
- Once a smart contract is deployed it CANNOT be changed. It is permanently stamped into the blockchain. This is a disadvantage to developing anything complex with potential bugs. I want to be able to update my code.
- Though blockchain, the ICP allows for applications to be updated. This can be done by the application's owner but I'm most excited for the Service Network System (SNS) which is like the NNS but for an application. So an application can still be updated, but it's controlled by the community.
- For a smart contract to work (like in Ethereum), an end user has to pay a fee for every call to that contract (and fees are insane right now). So every 'server' call has to be approved and paid for by the user. No one wants a web experience like this.
- The IC flips this model and has the owner of an application fund its computation, like current cloud models. This allows for users to have a seamless experience with smart contracts and only have to pay fees when the developer wants them to.
- The current state of smart contracts require many seconds or minutes for execution. This is unusable as a web replacement. Current smart contract applications run web 2.0 for everything except when a blockchain is absolutely needed. That is not a sustainable and/or scalable model.
- ICP only requires a few seconds for blockchain modifications and a sub-second for reading. Though this is slower than Web 2.0, it's usable in a web context.
My first project is the un-sexy work of encoding, parsing, and infrastructure work in .NET. As a developer I want to understand the protocol, starting with Types and the HTTP Interface. I used my knowledge of .NET to implement a library that allows .NET code to communicate to the Internet Computer over HTTP. This took me down a rabbit hole, reading messages byte by byte, that I never would have seen without doing it myself.
Collection of Internet Computer Protocol (ICP) libraries for .NET/Blazor
- Library to communicate to and from the Internet Computer
EdjCase.ICP.Agent(*currently only pre-release versions are available)
- Library of Candid Encoding, Models and Helpers
EdjCase.ICP.Candid(*currently only pre-release versions are available)
- A few projects to demo the capabilities of the ICP libraries
- A few projects to demo the capabilities of the ICP libraries
- Serialization for custom C# models
- Automatic Api Client/Model generation from Candid spec
- Infer type from value, vs specifying value + type
- DID file parsing
// Create identity var identity = new AnonymousIdentity() // Create http agent IAgent agent = new HttpAgent(identity); // Create Candid arg to send in request CandidArg arg = CandidArg.FromCandid( CandidValueWithType.FromValueAndType( // WIP, will reduce redundancy CandidPrimitive.Nat64(1234), new PrimitiveCandidTypeDefinition(CandidPrimitiveType.Nat64) ) ); // Make request to…
The library is functional but still needs some polish and features, so I will be staying with this project for the near future.
I plan on blogging some of my progress and thoughts on ICP as my journey continues, so stay tuned.