Cedalio

@ricardo_luz Hi Ricardo! Guido here co-founder & CTO. In a nutshell Cedalio uses smart-contracts to store access control rules, then each GraphQL operation before being executed by the gateway needs to be approved by the smart-contract for execution. Otherwise the operation is rejected. Then for operation that mutate the database, an operation log entry is created from the raw GraphQL operation and its execution context, persisted on IPFS and its CID is then committed into the smart-contract governing the database. Each operation log entry references the previous committed operation log entry CID. We are soon launching a verifier tool that would allow to reconstruct and verify any database that you own. We are also soon adding the possibility of verifying each GraphQL query response (client-side) by providing an SDK that computes the database merkle root hash (merkle root path will be accessible and persisted on IPFS) to check that the data comes from a database that hasn't been tampered and matches the operations accepted by the smart-contract. You can read more about Cedalio's design -> here https://docs.cedalio.com/technol...

@andrei_costea2 Thanks!

@budb Hi Bud, this is Guido co-founder and CTO at Cedalio. We are not EOS based, we can run on any EVM compatible chain. At the moment we are optimizing for Polygon PoS but we have plans to add support for other networks. In an nutshell Cedalio uses smart-contracts for access control, each operation must be allowed to be executed before being forwarded to the off-chain database layer. Then operations that update the state of the database are committed into an operation log. Each operation log entry contains the raw GraphQL operation plus the execution context. The operation log entry is persisted on IPFS and its CID committed into the smart-contract. Each operation log entry points to the previous committed operation log entry CID. You can read more about how Cedalio is designed here -> https://docs.cedalio.com/technol...

@guidomb_cedalio my only worry with this model would be the hyper limited nature of EVMs/Bridges, as they’ve consistently shown their lack of ability to handle large amounts of data without requiring centralization, which would defeat the point of using blockchain. curious why choose an ethereum-based layer 2 over other layer-1 networks that offer higher throughput and have more current technology that doesn’t rely on virtual machines or bridges?

@budb We have chosen Polygon as the first supported network for reasons, some of them being: the team had experience building on it, we think that the network has proven to be secure and reliable, transaction costs are cheap enough for our use case and Polygon has a strong brand which helps we talk with potential customers that are not too familiarized with the web3 ecosystem, which at the moment is our target audience. That being said, we are planning to add support for other EVM compatible networks specially on the zkEVM side like zkSync Era and Polygon's zkEVM. We are more that open to explore other chains if we see that there is enough demand for it.

@bballinger Yeap totally this is something that we are working on. Can't provide an ETA yet but for sure this is something that we are exploring

@bballinger Feel free to join our Discord https://discord.com/invite/kSdhm... or contact me directly at guido@cedalio.com. I'd love to know more about how we can help you

@anna_starodub1 Thanks!

@bruno_volcovinsky Thanks Bruno! In a nutshell Cedalio uses smart-contracts to store access control rules, then each GraphQL operation before being executed by the gateway needs to be approved by the smart-contract for execution. Otherwise the operation is rejected. Then for operation that mutate the database, an operation log entry is created from the raw GraphQL operation and its execution context, persisted on IPFS and its CID is then committed into the smart-contract governing the database. Each operation log entry references the previous committed operation log entry CID. Data stored on chain: 1. Access rules. Basically a mapping between address and a compressed representation of which object types and which fields that address can access (read, write or both) 2. CID of the latest committed operation log entry that's persisted on IPFS. Currently the operation log is not encrypted but we are working on adding encryption pretty soon. Only the database / smart-contract owner (and the gateway delegate) will be able to decrypt it. As for auditability, all operations before being executed in the off-chain database need to be approved by the smart-contract and then committed to the operation log (soon to be encrypted). We will also soon launch a tool that will let database owners reconstruct and verify their database (for example is they no longer want Cedalio to be the gateway). Also we are working on providing an SDK for application to verify client-side that the response from a query is valid, meaning that the data is derived from database that was "accepted" by the smart-contract. The SDK will compute the database merkle root hash client-side and compare it to the latest database merkle root hash committed in the operation log. In order to do this we will provide access to the merkle root paths via IPFS. Merkle paths are computed from the each object fields until we get to the root of the database. Finally because access rules are on chain, users can check (and we will provide a tool make this easier) who allowed access to which address. Only the database owner and delegate (Cedalio's gateway) can modify the access rules. Then if a third-party wants to read data from your database you need to explicitly grant access to it and by doing an on chain transaction is executed to update the access rules. You can read more about Cedalio's design -> here https://docs.cedalio.com/technol...