Solving "The Right to be Forgotten" for Blockchains

Hey, I'm gonna have to go through this quickly, cuz this is a little bit longer than a 20 minute session. But anyway, the topic is blockchain versus the right to be forgotten. It's been kind of presumed that blockchain and the right to be forgotten don't work together. So we're gonna talk about the inherent conflict between blockchain and privacy regulations. Rethinking the concept of immutability, a couple scenarios to resolve the conflict, some flow charts of alternatives, and then some real world implementation issues.

The conflict that we're all familiar with on the right, we have blockchains. One of the most important features of a blockchain is immutability that it can't be changed on the left. We have various privacy regulations that continue to accumulate as different jurisdictions put them out. And part of the requirements of many of these is kind of the right to be forgotten, to be able to have some information that once posted can be taken down. And that kind of goes right against that Tene of immutability of blockchains. So it's created a conflict. So can we actually support the right to eraser?

Can we actually re erase things on a blockchain and still maintain it's immutability and its integrity? Well, obviously you can't change something and also call it immutable. But what you can do is rethink the whole notion of how these things happen. And the concept I've come up with was one of actual versioning. So when rethink immutability, these highlighted areas in red are, let's say transactions that for whatever reason we wanna remove it doesn't matter what the content is. These happen to be numbers just cuz it was easy to display.

It could be obviously personal information is more likely that you'd wanna have things removed your picture from college college drinking party may not be something you wanna feature have featured. If someone's doing research on you, cuz you're looking for a new job. Those are kind of obvious examples. So how do we remove selected records? And the concept I came up with, as they say is versioning, where we'd have different versions of the blockchain. They would not be concurrent. They would be sequential.

Think about it as, as a bank statement or a credit card statement where your statement what's live to you is starts with a beginning balance for a particular period. Let's say a month. It shows all the transactions for the month and then it ultimately comes down to it and shows a closing balance. The notion is see only the transactions in the future or the transactions in the current period, but all the previous transactions are still, they're still held by the bank. The bank has that record, but it's not necessarily accessible to you.

So the notion is to take an original blockchain, which is this blue database. And we summarize what's in that blockchain, basically creating similar to like a, a closing balance for that particular period. But in that closing balance, we remove certain transactions and that closing balance is what I'm calling the net state. The original blockchain is still there. All the transactions are still there. All the data is still there. It's just archived. And that would be depend on various legal requirements for data retention and for the right to eraser.

It will de you know, depend on the stakeholders of the blockchain will have to agree to how this would be handled. And you create a supplement that begins with that. Now opening balance handles all the transactions that going forward, excuse me. And then you create a second supplement where you again, find more or less the net state of that first supplement and use that as the seed block for the second supplement.

So again, you in an archive that first supplement, so all the records are still there. You still have the immutable blockchain. If you ever have to do some tracking of transactions back in history, but going forward, you've been able to remove selected Transactions. Obviously the, if you just remove the transactions, you would have an integrity problem that would show up immediately because you have, have removed them, but you're not actually removing them from the archival record. They're all the archival record is complete.

They're only being removed from the closing balance summary of that archive. And in doing so you obviously would have to remind transactions, although this could be done in an automated fashion because the transactions themselves have all been validated and the historical archive record is there to be able to ensure that the integrity of the summary statement. So you're basically reshuffling the deck at a periodic basis. Some of these in the interest of time, actually I'll I'll show this part. So in a transaction a time zero Analyst has 20 assets.

They could be Bitcoin, they could be widgets, whatever it is it time one Alice and, and the net state is that there are 20 of these assets. Alice at time, one gives five of those assets to Bob. So she now has 15. Bob has five. Carol has zero. The net state remains 20 at time. Two Bob gives his five assets to Carol. So Alice now has 15. Bob has zero. Carol has five. And then that state again remains at 20. When we create the archive and remove Bob because he's asked to be, have his transactions removed.

You'll note that the beginning balance is 20 and the ending balance is 20 in the middle, in the great out portion. You see that at one point, the net state is 15, but that part is not actually part of the record anymore. That won't be part of the record going forward. The archive record ends with the beginning balance and the net state at T4 using that ending balance is what you use going forward to create the next supplement. And so you always maintain a net state of 20 so that you have integrity of the overall blockchain.

Now there are a couple different ways of creating these new supplements. One simple way is just to use the opening use closing balance from the archive as the opening balance. And you would then remove all you, well, you would have is you wouldn't have the transactions themselves. You would just have the opening balances.

So you would actually remove all the transactions, but you would re from the opening balance, but you would specifically remove from those opening balances, any references in this case to Bob, another way to do it is to actually just remove particular qualifying transactions. Instead of using that net state going forward, you could actually have transactions. You could maintain the entirety of the database, but just going forward, you'd have to remove certain transactions.

The third way is to create substitute transactions where you nullify the values of in this case, Bob, where maybe you would replace Bob's account ID with 9, 9, 9, 9, just some general number so that it can't be traced individually to Bob cuz you're removing multiple records, all of which show up as 9, 9, 9, 9, or some other particular value so that you can't distinguish which transactions are of these people. Who've asked to be removed from the record. There's some real world implementation issues.

Obviously, while these can work with these can work with most, any blockchain subject, obviously to the governance that blockchain and the stakeholders agreeing to use it. But, and it requires the approval of the group that governs the blockchain. This might be a decentralized group of stakeholders. It could be a corporate government or other owner sponsor I'm envisioning in the future.

There's gonna be a lot of enterprise blockchains that are specific to particular industries that will have owners, which makes them even more subject to privacy regulations than when you have decentralized bodies. And there's no no identifiable person for the regulations to be applied to. There'll be a cost of reshuffling. This could be an automated process, but if you insist on using something like proof of work or proof of stake, you might have to incentivize your minors to reshuffle the deck each time.

And there's a, there could be a cost to that, but the transactions we're all paid for once. So using the automated process would be presumably acceptable. The rules to qualify records for removal will be dependent on the types of transactions that are on the blockchain. If it's a supply chain and you just wanna remove yourself from the supply chain, that's one thing. If it's a social network, that's now using the blockchain, obviously you might want to, as they say, remove your embarrassing photos or other references, You don't need net state calculations.

If you're just removing something like a photo, because it doesn't have a life beyond that photo. The obvious question is what happens about all the other copies of the blockchain. Once people have a copy, they may choose to retain that copy, but that's a problem that exists for all of privacy. Once something's been published, can copy it. You can look at the way back machine possibly and find prior records, but that's beyond the control and scope of a blockchain. And that's not a problem we can solve here, but the same technique can also used for other purposes.

One of them is to avoid blockchain lock in. If you establish a blockchain for a particular industry, let's say for supply chain for the hockey equipment industry, but you establish it on Ethereum and you then decide, you know, Ethereum, the transaction costs are so high. We wanna create our own private blockchain. How do we get our transactions off? And this would be a way to do so. You could start with the net state instead of having to recap all the transactions on the Ethereum blockchain.

And I've come up with a concept called anti transactions, which would allow you, if you migrate assets from one, from, let's say Ethereum to this new private blockchain, you could put in anti transactions to Ethereum so that you don't double count and have, you know, a hundred hockey sticks on still on Ethereum. And now you move those hundred hockey sticks to the new blockchain. You don't wanna have a hundred on both. So you could have an anti transaction, which would negate the a hundred hockey sticks that are on, on the Ethereum blockchain.

You can also consolidate, you might have a sporting goods industry that decides we have blockchains for hockey. We have blockchains for football. We have blockchains for skiing. We want them all in one place because we don't wanna have to manage 16 different blockchains for all the different sports. There are. So you can go many to one. You can also do one to many and many to many using the same basic techniques. And if you have any questions, I'll take them now.