At the 2022 Compute Over Data Summit, Fission's co-founder and CTO Brooklyn Zelenka gave a presentation on how UCANs help enable computation in distributed systems.
The Bacalhau Project seeks to help users manage large amounts of data by providing developers with decentralized tools that are collaborative and efficient. Developers can compute over vast amounts of data by leveraging the peer-to-peer Bacalhau network of shared compute resources and IPFS Network's content addressing structure. Users never have to move the data itself to a central server to run the calculations. That's because large amounts of data can be represented by hashes, thus requiring less energy to run the necessary operations.
At Bacalhau's Compute Over Data Summit (Bacalhau is the Portuguese word for cod, and the Compute Over Data acronym spells out "cod" 😉), Fission's co-founder and CTO Brooklyn Zelenka gave two presentations. One was called IPVM: The Long Fabled Execution Layer, and the other was called Decentralized Authentication . The former is mainly a recap of the IPFS Thing presentation that Brooklyn gave earlier in the year, and you can view the CoD presentation on YouTube. The latter is what we'll focus on today, in which Brooklyn explains the ins and outs of UCANs.
UCANs stands for User Controlled Authorization Networks. They enable ways of authorizing offline-first apps and distributed systems. We previously shared a more technical break down of UCANs on the blog, and today we'll be discussing UCANs within the context of computation.
Solving Locality Problems
Traditionally, when a developer wants to interact with services that have access to data, the different parts of the network have to have individual agreements with one another, and the developer has to pre-negotiate tokens in order to interact with each part. This is because you need an authorization server, located in a specific place, that can handle these negotiation requests and agreements.
In distributed systems using content addressing, we are able to use capabilities rather than an authorization server. Therefore, location becomes a non-issue and the compute and the data are able to move about freely!
What is a Capability?
A capability defines what the issuer is granting permission for, and what the recipient can do with that permission. It is entirely defined by the person issuing the UCAN and the ability for the recipient service to understand the request. This means a wide variety of capabilities can exist.
Capabilities in UCANs are also fully extensible, so you can add more fields to restrict a recipient's permissions.
And the best part is you don't need anything further for invocation! So the compute over data can take place right where you are, enabling distributed RPC.
Chain Witnesses
Furthermore, in-browser cryptographic keys and offline compute means users can keep off of external systems entirely. The public and private keys that are now built into browsers can interoperate and connect to each other securely, and the user need only select the specific subset of data they want to compute over and then send the diff back to the network. All of this is made possible through content addressing and chain witnesses.
Chain witnesses are the individuals (people or software agents) that have been granted varying levels of access to a piece of content. It is possible to walk up the chain and see who delegated which permissions to whom, thus allowing the service to verify access.
Issuers can also revoke access to specific users and anyone downstream from them.
Learn more about UCANs and decentralized authentication by viewing Brooklyn's full presentation below:
Brooklyn's presentation slides are also available.