We are building an identity solution that drives from a face scan. We will implement OAuth 2.0 or Open ID connect to utilize this stack for direct passwordless authentication. We are considering implementing this into the blockchain ecosystem with various options. Since ICP is not just a chain, deploying everything here is also possible, but we like to know specific details.
1)Is keeping a significant part of the code private possible?
2)We need to run a db for this app. Can we make that private?
3)How does scaling work? Do we need to optimize scaling accordingly is there any limits? (There is a significant difference between matching a hashed map with db of 10k users to 10m users we need to keep match time low)
4)There are also 3rd party service possibilities. The payment processor is one of them. Considering these services require updates and keys could require changes. Is this process possible, or you update the whole app? How do these processes work?
To summarise how our product works. You get to the webpage which runs the SDK on your browser. The user scans their face with the camera. User’s devices calculate specific points, like the distance between eyes from that scan on their device, after verifying it’s human. Use these points, encrypt them, and send them to the backend; the backend matches it with the existing DB of users. If the hash matches, it succeeds; otherwise, it fails. Considering the ICP’s identity framework, we believe it can be beneficial there as one of the factors for security. While that’s a long stretch, that’s the general aim of our product, even if we deploy on aws/gcp infra.
Considering all these, if you can share some details and documentation on these areas, that would be very helpful to us.
Welcome and great that you are considering the Internet Computer as a platform to build your solution on.
It’d be great if you could provide more details on the architecture and flows you’re envisioning, but I’ll try to answer your concrete questions:
The canister code and state (memory) are not public on the IC (only the hash of the compiled wasm byte code). However, Boundary Nodes and node providers of the specific subnet can, with some effort, access the wasm byte code. Node providers are assigned by the Network Nervous System, so they are known entities, and not everybody can just run a node and get access to your canister code. It’s a bit similar to running code on a cloud provider, but on the IC there are always multiple “providers” that run your code. However, we are working on making it very hard for node providers to access the code and state of the canisters.
yes, there are instruction/cycle limits on query and update calls. But we have e.g. the Bitcoin canister running on the IC which provides access to the Bitcoin UTXO set which has almost 90 million entries, so I guess it should be possible given a properly designed data structure. You also have the possibility to shard your state into multiple canisters (see e.g. https://www.canscale.dev/)
I don’t understand the question regarding 3rd party service possibilities, but canisters can be upgraded.
Each canister can have a list of controllers with permission to upgrade the code. Initially, canisters are typically controlled by the developers. Eventually, canisters should be (in most cases) controlled by other canisters such as a DAO or release management canister.
There’s also an upcoming feature that provides more features regarding on-chain encryption which might be of interest to you. Check out this thread.
I am talking about integrating plugins like for example stripe for payment processing. Is this even possible from my understanding everything runs on mokoto language. What I am trying to ask is if there is 3rd party service which we can’t make adjustment under the terms we are signing for utilizing this service. Is there any way of compatibility layer for running it on mokoto as it is? If not only way would be integrating that codebase to mokoto while as I stated that’s not always a possibility legally.