Technical Details

Index

  1. Program schema
  2. User schema
  3. Token schema
  4. SN Stack and Units engine

Program Schema

The program can be any smart contract. We will be using the Cairo programming language to start with as that’s very efficient for ZK proving. However, eventually, support for more programs can be added. Every program in UNITS must be thought of as a fundamental provable unit (will come to what this means later).

As a developer, what you need to know is that if you deploy a program on UNITS

  1. You get a specific storage for your program that can only be accessed by functions of your program
    1. This may seem intuitive but in the blockchain world, the DB of all programs is public and accessible. There is no private information (which also contributes to a lot of hacks)
  2. You can define your functions as private, authenticated or public.
    1. Private functions are only accessible via other functions of the program
    2. Authenticated functions define who can access the program. The developer gets to decide these checks as he/she writes the program.
      1. For example, assume your token program for fractionalized gold has a function called fn balanceOf(address). This allows someone to read the balance of any address. The token developer can set authentication with the program that this function can either be called by
        1. The owner of the address (prove by signing with public key of address)
        2. The token manager
    3. Public functions which can be accessed by anyone who has an UNITS endpoint
  3. Your program can be called by users outside UNITS or by other program inside UNITS as long as they’re authenticated to do so.

Screenshot 2025-03-23 at 3.00.00 PM.png

<aside> 💡

If we divide permissions into two types - read and write, then most of the current blockchain world ONLY enforces write permissions. This means, it’s impossible to change state of a token without authorisation from the owner of the token themselves.

However, one of the criteria of being a public blockchain is that nodes can join the network permissionlessly and replicate the state of the chain on their hardware. As a result, there’s no merit in defining read permissions. The entire state of any public chain can by synced on anyones hardware and there’s no confidentiality of state.

Yes, smart contracts have private functions even today. However, private functions today do NOT ensure data confidentiality. They only ensure that other smart contracts cannot call these functions.

This is different in UNITS. Over here, we’ve an operator who has read access to all data. However, we allow developers to define read ACLs in their program and we expect the UNITS operator to enforce the read ACLs. One thing to make clear here is that the only way read ACLs are enforced is via trust. It’s impossible to prove that the UNITS operator has not shared private data off chain to some actor. I believe there are some solutions to this in a post quantum world but we’re not there yet 😟.

It’s also important to mention that write ACLs are guaranteed via ZK. If the UNITS operator changes state of some token that they do NOT have permission for, they would NOT be able to generate a valid ZK proof for the same.

</aside>

At a fundamental level, every program inside UNITS must be assumed to be a provable block of code. As a developer, this means that