3 ms·

A database that is verifiable and auditable by default

13 points by guidomb 3y ago

guidomb 3y ago
What do you think?
pavel_lishin 3y ago
What's the advantage of all of this being distributed - including on IPFS - vs. using "block chain technology" to sign writes, etc, to something locally stored? And if I'm trying to sell this to my boss, how do I get past "everything is on someone else's chain & machines that we don't control"?
- guidomb 3y ago
  The advantage of being distributed and using IPFS is that you don't need to rely on Cedalio to be alive to access your data. You can spin up your own Cedalio gateway connect to the network where the smart-contract backing your data lives and recover the database. The advantage of using blockchain is that you can proove that the data being stored in the off-chain database hasn't been tampered with and by having the access control on-chain you have full controll on who can access the data. Also because the operation log is replicated on IPFS you can see who mutated the database. As for locally stored if you mean using a local database (or file) inside the app, e.g: SQLite, CoreData or IndexDB, that may be good enough for your local use case. But if third parties or other apps need to access data without having to rely on the application owner to be connected / available you need a database that can be accesed over the internet / network. If by local you mean a regular SQL database exposed over an web service, that may also be good enough for your use case. The benefit of using something like Cedalio, is that in cases where you need guarantees that the data hasn't been manipulated by users that shouldn't have then you have a trust-free setup to do so. We are talking with users where this is a requirement specially to avoid internal fraud (from the db admins for example). The last point of 'how do I get past "everything is on someone else's chain & machines that we don't control"?' this is the same trade-off that you currently have with any PaaS / SaaS tool. That being said, we plan to open source our gateway so you will be able to host your own infra and you will own the off-chain database. As for the data that's stored on chain, we only store the ACL and hashes of the committed operation in the operation log. The operation log currently is stored in plain text on IPFS but we are soon launching operation log encryption. We also plan to make the operation log storage configurable, if you don't care about data ownership / portability (meaning that you don't want to give an option to your users to migrate from your service without having to ask for it) then you could use AWS S3 or whatever storage that you see fit. Full disclosure I'm Cedalio's CTO
theamk 3y ago
1. It was surprisingly hard to find out which blockhain is being used... Looks like it is some sort of testnet for now, with future plans for Ethereum? 2. As most blockchain startups do, this has the usual failure mode of losing access to the private key (or having hackers get hold of it, both are bad) and having no recovery whatsoever. Given how often we read about large orgs having embarrassing IT failures and data leaks, I cannot imagine any sane CIO using a system without account recovery mechanism.
- guidomb 3y ago
  Hi! I'm Guido, co-founder & CTO at Cedalio. 1. We are currently using Polygon Mumbai (testnet) and haven't enabled mainnet yet. We are testing the system with some customers and gradually deploying them on mainnet. We plan to launch mainnet in public access by the end of September. Cedalio works with any EVM compatible chain, we plan to add support for Polygon zkEVM and zkSync's Era network. Open to evaluate other chains as well. 2. Regarding security and failure modes, first let me give you a high level overview of how the system works, you can find more info in https://docs.cedalio.com/technology/solution-blueprint https://docs.cedalio.com/technology/solution-blueprint. Each database deployed on Cedalio stores its data off-chain and has a matching smart-contract deployed when the database is created. That smart-contract is owned by the wallet deploying the database (the end-user), we don't hold that wallet's private key. The smart-contract also has a delegate wallet, which is managed by Cedalio. We do hold the private key for the delegate address. The owner is the only one that can set who the delegate is. The delegate has full read/write access to the database. This allows our gateway to operate on behalf of the database owner. If you use Cedalio you are trusting our gateway to access your data but at any point in time you can bypass Cedalio, remove our wallet as the delegate and from that point on you can spin up your own gateway and re-route traffic to your gateway instead of ours. We think that for the use cases that we are targeting this is a reasonable trade-off. We plan to make the gateway open source by the end of the year. Regarding recovery, all mutation operations excuted against the off-chain database are replicated in an operation log that's encrypted and stored on IPFS. Only the database owner or the delegate can decrypt the operation log. If we loose the delegate keys, the owner can always recover the data even if Cedalio is not avaiable. If storing the operation log on a publicly accessible storage network like IPFS (eventhough is encrypted) is not secure enough for our user's use case, we plan to offer other storage provider (like using AWS S3 or any other solution behind a VPC). We default to IPFS for the operation log to ensure that database owner have access to the replication log and can always recover data without needing to coordinate with Cedalio. As for the encryption schema, currently we have a symetric encryption scheme but we are working on using https://litprotocol.com/ https://litprotocol.com/ for further decentralization and programability on who can decrypt the operation log. Our current solution, involves us being the ones storing and managing the private keys for the delegate wallets. Wallets are generated on per project basis and securely stored. If one wallet is compromissed, it could only access a single project not all the projects within Cedalio. That being said we are exploring two possible options to further reduce this risk. 1) using MPC wallets 2) implementing an option where you could connect a signer service, and therefore we don't need to have a delegate and the database owner is the one managing the signer infra and therefore custoding the private key. Both of these solutions have implications on devx and cost but we plan to offer them. Finally we think that our product does not have a different security risk compared to any other database saas (e.g: MongoDB Atlas, Grafbase, Heroku Postgres, etc). Meaning that we need to implement all the industry standard security meassures that any other database / saas company need to implement in other to secure its customer data. We think our use case does not compare to, lets say a blockchain brige or an exchage that has custody of the end-user token balances or any other scenario where transactions cannot be reversed. In our case, the only thing that we are storing on the smart-contract is the database's ACL and the hash/CID of the latest operation commited into the operation log. Data can be recovered. That being said, the risk of being hacked is that if an attacker gains access to a database delegate wallet private key, they can access the user's data but this is the same risk any other database / SaaS company has. Let me know if there is anything that needs clarification.

13 points by guidomb 3y ago

What do you think?

What's the advantage of all of this being distributed - including on IPFS - vs. using "block chain technology" to sign writes, etc, to something locally stored? And if I'm trying to sell this to my boss, how do I get past "everything is on someone else's chain & machines that we don't control"?

guidomb 3y ago
The advantage of being distributed and using IPFS is that you don't need to rely on Cedalio to be alive to access your data. You can spin up your own Cedalio gateway connect to the network where the smart-contract backing your data lives and recover the database. The advantage of using blockchain is that you can proove that the data being stored in the off-chain database hasn't been tampered with and by having the access control on-chain you have full controll on who can access the data. Also because the operation log is replicated on IPFS you can see who mutated the database. As for locally stored if you mean using a local database (or file) inside the app, e.g: SQLite, CoreData or IndexDB, that may be good enough for your local use case. But if third parties or other apps need to access data without having to rely on the application owner to be connected / available you need a database that can be accesed over the internet / network. If by local you mean a regular SQL database exposed over an web service, that may also be good enough for your use case. The benefit of using something like Cedalio, is that in cases where you need guarantees that the data hasn't been manipulated by users that shouldn't have then you have a trust-free setup to do so. We are talking with users where this is a requirement specially to avoid internal fraud (from the db admins for example). The last point of 'how do I get past "everything is on someone else's chain & machines that we don't control"?' this is the same trade-off that you currently have with any PaaS / SaaS tool. That being said, we plan to open source our gateway so you will be able to host your own infra and you will own the off-chain database. As for the data that's stored on chain, we only store the ACL and hashes of the committed operation in the operation log. The operation log currently is stored in plain text on IPFS but we are soon launching operation log encryption. We also plan to make the operation log storage configurable, if you don't care about data ownership / portability (meaning that you don't want to give an option to your users to migrate from your service without having to ask for it) then you could use AWS S3 or whatever storage that you see fit. Full disclosure I'm Cedalio's CTO

theamk 3y ago

1. It was surprisingly hard to find out which blockhain is being used... Looks like it is some sort of testnet for now, with future plans for Ethereum? 2. As most blockchain startups do, this has the usual failure mode of losing access to the private key (or having hackers get hold of it, both are bad) and having no recovery whatsoever. Given how often we read about large orgs having embarrassing IT failures and data leaks, I cannot imagine any sane CIO using a system without account recovery mechanism.

guidomb 3y ago
Hi! I'm Guido, co-founder & CTO at Cedalio. 1. We are currently using Polygon Mumbai (testnet) and haven't enabled mainnet yet. We are testing the system with some customers and gradually deploying them on mainnet. We plan to launch mainnet in public access by the end of September. Cedalio works with any EVM compatible chain, we plan to add support for Polygon zkEVM and zkSync's Era network. Open to evaluate other chains as well. 2. Regarding security and failure modes, first let me give you a high level overview of how the system works, you can find more info in https://docs.cedalio.com/technology/solution-blueprint https://docs.cedalio.com/technology/solution-blueprint. Each database deployed on Cedalio stores its data off-chain and has a matching smart-contract deployed when the database is created. That smart-contract is owned by the wallet deploying the database (the end-user), we don't hold that wallet's private key. The smart-contract also has a delegate wallet, which is managed by Cedalio. We do hold the private key for the delegate address. The owner is the only one that can set who the delegate is. The delegate has full read/write access to the database. This allows our gateway to operate on behalf of the database owner. If you use Cedalio you are trusting our gateway to access your data but at any point in time you can bypass Cedalio, remove our wallet as the delegate and from that point on you can spin up your own gateway and re-route traffic to your gateway instead of ours. We think that for the use cases that we are targeting this is a reasonable trade-off. We plan to make the gateway open source by the end of the year. Regarding recovery, all mutation operations excuted against the off-chain database are replicated in an operation log that's encrypted and stored on IPFS. Only the database owner or the delegate can decrypt the operation log. If we loose the delegate keys, the owner can always recover the data even if Cedalio is not avaiable. If storing the operation log on a publicly accessible storage network like IPFS (eventhough is encrypted) is not secure enough for our user's use case, we plan to offer other storage provider (like using AWS S3 or any other solution behind a VPC). We default to IPFS for the operation log to ensure that database owner have access to the replication log and can always recover data without needing to coordinate with Cedalio. As for the encryption schema, currently we have a symetric encryption scheme but we are working on using https://litprotocol.com/ https://litprotocol.com/ for further decentralization and programability on who can decrypt the operation log. Our current solution, involves us being the ones storing and managing the private keys for the delegate wallets. Wallets are generated on per project basis and securely stored. If one wallet is compromissed, it could only access a single project not all the projects within Cedalio. That being said we are exploring two possible options to further reduce this risk. 1) using MPC wallets 2) implementing an option where you could connect a signer service, and therefore we don't need to have a delegate and the database owner is the one managing the signer infra and therefore custoding the private key. Both of these solutions have implications on devx and cost but we plan to offer them. Finally we think that our product does not have a different security risk compared to any other database saas (e.g: MongoDB Atlas, Grafbase, Heroku Postgres, etc). Meaning that we need to implement all the industry standard security meassures that any other database / saas company need to implement in other to secure its customer data. We think our use case does not compare to, lets say a blockchain brige or an exchage that has custody of the end-user token balances or any other scenario where transactions cannot be reversed. In our case, the only thing that we are storing on the smart-contract is the database's ACL and the hash/CID of the latest operation commited into the operation log. Data can be recovered. That being said, the risk of being hacked is that if an attacker gains access to a database delegate wallet private key, they can access the user's data but this is the same risk any other database / SaaS company has. Let me know if there is anything that needs clarification.