Why should a compliance professional care about this?
I spend a good part of my days thinking about how to protect personal data. LGPD (Brazilian General Data Protection Law), privacy policies, legal bases — that's my world. When I started studying blockchain seriously, I realized that it wasn't enough to understand what the technology does. I needed to understand how information enters this network and why, once it's in, it's practically impossible to remove it.
This "practically impossible" is what keeps those who work with compliance awake at night. But before entering this debate — which will be the heart of this 30-day campaign — we need to understand the basic mechanics. How does a transaction originate, travel through the network, and become permanent?
I'll explain without a single line of code. I promise.
The analogy of the digital notary office
Think of a notary office. You go there, sign a document, the notary recognizes your signature, registers everything in a book, and stamps it with the date and time. From that moment on, that record officially exists.
A blockchain transaction follows a similar logic — only without the notary. There is no person or company at the center deciding what is valid. The entire network plays this role. And the "registry book" isn't kept in just one place: it's copied on thousands of computers around the world.
Does that seem excessive? It's precisely this excessiveness that makes things secure. And it's this same excessiveness that creates the challenge for the LGPD (Brazilian General Data Protection Law).
The five stages of a transaction
- Creation — "I want to register something" It all starts with an intention. Someone wants to send a value, register data, or perform an action on the network. This intention becomes a "transaction" — a package of information that basically says: who is sending, to whom, and what.
Think of it like filling out a form at the registry office. You haven't registered anything yet — you've only written what you want to do.
Connection with compliance: even at this stage, if the data being registered is personal, the LGPD comes into play. Article 7 requires a legal basis for any processing of personal data. The simple creation of a transaction containing a person's data is already "processing" under the law.
- Signature — "I confirm that it's me" Before submitting the form, you need to prove that it's you. In a physical notary's office, this would be your notarized signature. On the blockchain, there's a mechanism called a digital signature.
It works like this: you have two keys. One is like your safe's number (public — anyone can see it). The other is like the combination that opens the safe (private — only you know it). When you "sign" a transaction, you're using your private key to create a unique mark that anyone can verify using your public key, but that no one can forge.
It's as if your signature at the notary's office were impossible to copy. Literally impossible — not difficult, impossible.
Connection to compliance: the public key, although it doesn't contain your name, can be traced back to you under certain conditions. Article 12, §2 of the LGPD (Brazilian General Data Protection Law) states that data that can be used to identify someone, even indirectly, is personal data. A blockchain public key can fit this definition — and this is one of the most important debates in the field.
- Propagation — "Spreading the word" After being signed, the transaction is sent to the network. Imagine you handed your signed form not to a notary's office, but to a public square full of people. Each person who receives the information passes it on to others.
In a few seconds, thousands of computers (called "nodes" of the network) already have a copy of your transaction. It is not yet confirmed — it is in a "waiting room" called a mempool, waiting to be processed.
It's as if the notary's office had a queue: your document has been received, but it hasn't been stamped yet.
- Validation — "Checking if everything is correct" This is where the notary's office replaces the notary. Specialized computers (in the case of Bitcoin, called miners; in other networks, validators) take transactions from the waiting room and check:
Is the digital signature valid? Does the sender actually have what they claim to have?
Does the transaction follow all the network rules?
If something is wrong—a forged signature, insufficient funds, any irregularity—the transaction is rejected. No appeal, no "workaround." The rules are the same for everyone.
Imagine a group of independent accountants, each checking the same spreadsheet. If the majority agree that the accounts balance, the transaction is approved.
Compliance connection: this decentralized validation is fascinating from the perspective of Article 46 of the LGPD (Brazilian General Data Protection Law), which requires "security measures capable of protecting personal data." Distributed consensus validation is, technically, one of the most robust ways to guarantee data integrity that we have ever invented. But who is the "controller" responsible for this validation? The entire network? Nobody? That's another open question.
- Inclusion in the Block — "Stamped and Archived Forever" Approved transactions are grouped into a block — think of it as a page in a notary's ledger. This page receives a unique stamp (called a hash) that functions like a fingerprint: if someone tries to alter even a comma on the page, the stamp changes completely, and everyone notices the fraud.
But the crucial detail is this: each new page contains the stamp of the previous page. This creates a chain — hence the name blockchain (chain of blocks). To alter an old transaction, you would need to redo all subsequent pages on thousands of computers simultaneously. In practice, this is unfeasible.
The transaction is now permanent. It's in the ledger. The ledger is in thousands of places. No one can tear the page out.
Connection with compliance: and this is exactly where the paradox lies. Article 18, item VI of the LGPD (Brazilian General Data Protection Law) guarantees the data subject the right to the deletion of personal data. But how do you delete something from a book that, by design, was made to be unalterable? This conflict between technical immutability and the legal right to be forgotten is the theme we will explore throughout this campaign.
What I learned building DPO2U
When I started developing DPO2U — a tool that attempts to reconcile blockchain with data protection — I thought the biggest challenge would be technical. Code, contracts, infrastructure.
I was wrong. The biggest challenge is conceptual. It's understanding that blockchain wasn't designed with privacy in mind. It was designed with transparency and immutability in mind. And the LGPD (Brazilian General Data Protection Law) wasn't designed with blockchain in mind. It was designed with traditional databases in mind that can be edited and deleted.
These two logics are on a collision course. And understanding the mechanics of a transaction — how it is created, validated, and becomes permanent — is the first step in understanding why this collision is so difficult to resolve.
Where are we going tomorrow?
Now that you know how a transaction becomes irreversible, the natural question is: what if I need to delete this data? If the LGPD (Brazilian General Data Protection Law) gives me the right to request the deletion of my information, how does this work in a system that was built to never forget anything?
On Day 3, we'll dive headfirst into this conflict: the immutability of the blockchain versus the right to be forgotten. This is where the privacy paradox gets really interesting.
Top comments (0)