I have a question about the Safe DID method. We have submitted a grant proposal to develop a framework for building impact evaluators at scale. The framework would be built with the Autonolas tech stack, which is useful for decentralizing the off-chain components of dApps. The way it works is that multiple operators control an agent, which is a piece of code that can pull data, aggregate it, and submit transactions on the blockchain (think bots on steroids!). However, for the service to remain decentralized, these transactions are submitted on the blockchain via a Safe multisig, with each agent being a signer. This effectively makes the service act as an autonomous multisig.
We are interested in using this same functionality to write data to Ceramic via a Safe DID. We believe this could be a compelling use case for decentralizing the process of updating Ceramic data streams. Matt was under the impression that development on the Safe DID method had been paused, but he suggested checking with the community to make sure.
Is the Safe DID method operational and available to use for the grant proposal we have submitted? If so, can you provide any guidance on how to implement it in our framework?
Unfortunately did:safe and did:nft are not currently recommended for production usage due to a potential concern around how they interact with the security model for Ceramic.
There is a data withholding attack in Ceramic today where the controller of a stream could create a commit for a stream, get it anchored, but not tell anyone about it. Then, sometime far in the future after many more writes have been done to the stream, the malicious stream controller could reveal the secret commit it had made in the past. Since Ceramic uses an “earliest anchor wins” conflict resolution mechanism, and because the secret commit would have been anchored long before any of the more recent writes that have happened since, the malicious controller would effectively revert the stream back to the state it was at when the secret commit was authored, and blow away the history of any updates that happened since.
This isn’t a problem for most Ceramic streams today since all Streams have a single DID controller, and each DID generally corresponds to a single end user. There’s no incentive for a user to invalidate the history of their own streams. But for a DID method that allows changes to the set of real humans in control of the DID, this data withholding attack means that to use did:safe as a controller of a Ceramic stream, you need to trust all members of the Safe to be well behaved for all time. If a member is removed from the trusted group membership in the Safe, they could still be sitting on an unpublished commit that they could publish in the future to revert the stream state and discard history.
We hope to be able to fix this in the future with more sophisticated conflict resolution logic in Ceramic streams that leverage CRDTs to merge conflicting updates, so that even if a previous member of a Safe were to publish an old commit, that update would merge into the stream history rather than superseding and replacing all existing history. It would still be a kind of attack vector, but one that much more benign and easy to recover from.
