The problem Bellatrix Protocol solves

What can people use it for?

• People can use bellatrix protocol to create private blockchain where data of multiple stake holders is maintained. Since this is maintained in a private fashion, stakeholders outside of authority have to trust that people governing that data have not tampered with it. This is why we built a private chain which can be verified by some simple cryptographic proofs by anyone (without access to its private data). This can be used to replace private databases of bodies where data of multiple stakeholders is stored and requires verification capabailities.

• We think bodies such as police, banks (also the new cbdcs :D ), hospitals, and educational institutes can leverage this to enjoy benefits that a blockchain provides such as consensus based decision making while keeping their users data confidential but also give their users a way to trustlessly verify their integrity. It can also be used by DAOs to run private governance involving members from the outer ecosystem.

How it makes exisitng tasks easier and safer

• The solution provides an EVM equivalent client (a fork of go-ethereum) which can provide out of the box tooling for organizations with an easy to manage infra.

• With additional filtering for contract functions at the RPC layer of the client, developers can leverage it to create permissioned states for specific users and provide access control for contracts.

• People can verify the proofs submitted on L1 using zero knowledge circuits and assure that the chain is tamper proof and proves the continuity of chain.

• Data mutabiltiy and immutability can be managed by checkpointing (encrypyted) proof of integrity on IPFS. We have tried to do this at contract and dApp layer in our demo application.

Challenges we ran into

• The components of generating zk proofs for chain continuity and integrety were tricky to implement as we were looking for a middle ground solution which does not takes too much computation overhead by proving each and every state transitions (like a zkEVM). We decided upon using a batch of transactions hashes and merkelizing them as the proving points (and also the private inputs to our circuits) and only making the header chain public. One of the major pain point is having same set of hashing library implementation in the client (written in go) and the circom circuit. It was difficult to find a single suitable library which works and produces similar set of inputs for both the cases. As this wasn't technically possible, we choose to use a different way to prove and verify the data instead of a full-fledged mechanism integrated with the client and a zk circuit.

• While integrating with our private chain and using the WAGMI hooks for react for our demo app, we were facing problems in reading smart contract state.

• While implementing an easy to use encryption algorithm for pushing data on IPFS, we could not find any plug and. play solution for the same due to javascript versioning issues.

• We also wanted to have the graph indexer service natively available with our private chain but the docker based integration took too much additional compute and time for it to be available in the PoC.

• We wanted to deploy the demo app to StackOS, but due to technical concerns and incompatibility we weren't able to achieve it fully.