current position:Home>How to fully control the "read" permission of data on the blockchain

How to fully control the "read" permission of data on the blockchain

2022-06-24 02:35:05User 7358413

People often ask a question :“ How to realize the read permission of data on the chain in the contract ?”

Behind this demand , Developers want to link some data , Let smart contract management and Computing , To reach a business consensus , But I don't want the data to be publicly visible , Avoid other unauthorized participants in the chain from reading , Leading to information disclosure .

The most intuitive implementation idea , Is to write a piece of filtering logic in the contract code , Judge that the caller meets certain conditions ( If in the white list ) To allow data to be returned , Otherwise, refuse .

Let's set a case : There is an integral alliance chain , Participants in the chain have Alice、Bob、Carl、Dave And so on and their families , Everyone's point balance wants to be set to be visible only to themselves and their families , Other participants are not visible .

The client passes through the application level interface of the blockchain , Send a request to a node , Call the of the smart contract get Method check Bob Integral , The smart contract writes permission control logic , Refuse unauthorized access .

Because the operation logic of smart contract on each node is consistent , So no matter which node the request is sent to , The results are the same . It doesn't seem to be a problem , But is it true ?

Let's start with the conclusion : This is a “ Treat the symptoms, not the root cause ” How to do it , and You can't Make sure the data doesn't leak .

Now we're going to use “ Multicenter 、 To trust ” To re-examine this case .

Let's analyze first : How the data on the chain is stored ? Under what circumstances will it be leaked ?

Blockchain network nodes are distributed in the environment of different participants , Due to the data consistency of blockchain , Each node holds a complete copy of the data . Whether the database is LevelDB/RocksDB Such a file database , still Mysql Such a relational database , The data will fall into the database instance of each node .

in other words Bob Your point balance , A copy is saved on all node hard disks , stay MySQL Look in the database tool , About this :

If the chain ( With a small probability ) There is a participant with some experience in blockchain Technology , Secretly carrying “ malice ”( It's also known as Byzantine players ), He can open the local database with tools , Direct inquiry Bob Balance of . such , The control logic of using contracts to prevent data leakage will be completely bypassed . It's that simple .

in addition , Blockchain data is not only related to contracts , It is also closely related to transactions .

When sending a transaction , Transaction parameters may contain some or all of the data ( Such as Alice to Bob Transfer accounts 100), The trade will be packaged into blocks , Finally, it is also written to the node database .

The query of block and transaction data is generally not implemented by contract logic , therefore , Just writing filter logic in the contract does not prevent these data from being read . Byzantine players can traverse block data in the local database , Get transaction history details , Replay the transaction flow from beginning to end , Know now Bob The balance of is 300.

From the whole technology stack , Byzantine players use tools to access local data 、 Traversing blocks and trading are small things , He can even modify the blockchain system code , From the blockchain network interface 、 Program memory 、 Smart contract engine , From the protocol package 、 block 、 Transaction flow 、 Contract context 、 Status data and other links sniff and intercept plaintext data , Even if the data is encrypted , The key is also in the hands of the node holder , He can still untie .

therefore , Start with the underlying code of the blockchain to control the permission to read data , It also doesn't work , After all, open source code , Anyone can change , It is said that :“ Bad guys can do martial arts , No one can stop ”, And those who know technology “ The bad guys ” Even more omnipotent 、 impossible to guard against .

All in all , Blockchain emphasizes “ Share ” and “ Uniformity ”, As long as plaintext data is broadcast on the chain , Others have countless ways to get . Whether at the contract level or the underlying code , Almost all read control logic is like Window paper A poke will break , image Maginot Line The same is in vain .

See here , Someone might ask : Reading data is so unprotected , The blockchain “ Write ” Does permission still make sense ? The answer is : yes , we have .

Back to the example of integral , We set Alice It's the point manager , She can initiate the transfer of points , then Bob Only accept Alice Give yourself points . The transaction of transferring points needs to be agreed by the whole network , All consensus nodes will check the rules written in the contract , Refuse to sign if it does not meet the requirements , There is no consensus on ultra vires transactions , Then the data will not be modified .

Even if there are a few Byzantine nodes , No matter how you toss around on the local node , Can't tamper with the whole network data .

“ Write ” Trading pursues consensus , So the client sends a transaction (sendTransaction or sendRawTransaction) when , To put a digital signature , The blockchain system verifies the signature , Confirm which external account sent the transaction , It can be strictly verified and accurately traced .

“ read ” Operation emphasizes sharing , In fact, the operation of reading data does not go through the consensus process , Just flip through the data on your own node . Generally, the blockchain system reads the interface (call) You don't have to fill in the sender , There is no need for a digital signature , therefore , Judge the external account in the contract reading method , In fact, it is invalid .

Based on the above analysis , We can conclude that : Implementing read control on the chain is not a simple thing .

If the read control logic is not considered enough , Then the effect will be : You read the data on your own node to test and verify , It looks like OK, You think the years are quiet , But I don't know where a Byzantine player , The data has been turned upside down .

Considering the de trust in multi-party cooperation , Pursue data sharing 、 Open 、 Transparent orientation , Generally speaking , If it's critical 、 Sensitive data that cannot be disclosed , Be sure to chain carefully , Chainable , It must be something we agreed to share “ greatest common divisor ”.

In fact, the status of transactions and balances in many blockchain systems are visible throughout the network , The so-called anonymity or privacy , It just replaces the plaintext account with the public-private key and address system , At this level “ anonymous ”, In the financial system with complex business model and emphasis on comprehensive privacy 、 Areas such as government affairs do not apply .

So what else can we do , Taking into account sharing 、 transparent 、 Open at the same time , Properly control data visibility ?

The first idea is Combined with governance outside the chain , Agree on the boundary of responsibility and right . I'm on the contract 、 At the interface level, do a good job in authority design and implementation , Ensure no data leakage in my business system , My blockchain application layer 、 Display interface 、 report form 、 journal 、 Database and other links will not be accessed beyond their authority , Eliminate my internal operational risk .

As for other people's nodes , I can't tube , That's their responsibility , Who divulges and abuses data , Who will be severely punished ( obtain evidence 、 It's actually hard to prove ). This logic is actually a little “ Sweep the snow in front of each door ” It means , In this mode , My sensitive data still can't be linked to others .

The second idea is Introduce cryptography . Here are some examples .

Asymmetric encryption : The uplink data is encrypted with the recipient's public key , Only the receiver can unlock with its own private key .

Password envelope : Uplink data is encrypted with a password , The password is given to the receiver through the off chain channel , Only the receiver who knows the password can decrypt .

Property encryption : The data is encrypted by attribute encryption algorithm , Conform to the specified properties ( If it has administrator attribute ) To decrypt . The consideration of these schemes is the operation 、 transmission 、 The cost of storage will be a little higher , In addition, the encrypted data does not support plaintext operation , Difficult to implement complex business contract logic . Also note that , Even if it's dense , In essence, all the information of the data is still on the chain , Over time , Computing power and algorithm ( Such as quantum cryptography ) Evolution , There is a possibility of being brutally cracked , Or because of a key leak / Too simple to be guessed , The data on the chain cannot be withdrawn , There is a risk of being publicized .

The third idea is Only summary uplink , Data plaintext is not linked at all .

Actually , The role of blockchain is not necessarily to fully master data and execute complex business rules , But with the credibility of many witnesses , Verify the accuracy of the data 、 integrity , And play the role of deposit and traceability , In fact, many blockchain systems at this stage are mainly based on such logic , Objectively, it has been able to act as an anchor of trust .

If plaintext data is required , Then go to the off chain system to obtain data through the addressing information in the summary , Do fine permission control in this link , And cross check with the summary on the chain .

but , I'm still a little unwilling to link the data , Blockchain is such an innovative concept , Smart contracts are so powerful , How to give full play ?

This is about Privacy computing 了 , Including but not limited to zero knowledge proof 、 Homomorphic encryption 、 secure multi-party computation 、 Federal learning and a series of heavy weapons , Can do secret data 、 Identity at the same time , Encrypting data Addition, subtraction, multiplication and division 、 Logical operations 、 Sort 、 Statistical analysis , Further, you can do “ The front desk is anonymous , Background auditable ” The effect of , To meet regulatory compliance requirements . This is the realization of... On the blockchain “ Available not visible ” The ultimate meaning of .

Limited to space , The details of privacy computing are not expanded here , You can refer to WeDPR Open source scenario solutions related to privacy protection , Especially some of the scenes , Such as VCL Blockchain verifiable ciphertext ledger , It can be used to solve some privacy problems in the points case mentioned above .

WeDPR Open source scenario scheme related to privacy protection :

https://fintech.webank.com/wedpr/

VCL Blockchain verifiable ciphertext ledger :

https://sandbox.webank.com/wedpr/confidentialpayment/#/start

Conclusion

I just wanted to talk “ How to write contracts and read permissions ” Such a small problem , It turned into a long story .

In fact, in the face of blockchain programming and development , You really can't think like writing stand-alone or cluster software , We should fully consider multi-party participation 、 To trust the collaborative relationship in the environment , Sharing 、 transparent 、 On the basic philosophy of traceability , Pay attention to the demands of privacy protection , Weigh the importance and sensitivity of the data , Then go deep into the technology stack , Consider the efficacy and cost of various algorithms 、 Integrate current and future risks and benefits to select appropriate strategies , In this way, data and privacy can be fully protected , Develop business safely , Protect the rights and interests of itself and users .

copyright notice
author[User 7358413],Please bring the original link to reprint, thank you.
https://en.netfreeman.com/2022/175/20211028160926578S.html

Random recommended