에디터 | 캐롤

에디터 | 캐롤

"계약에서 체인에 있는 데이터의 읽기 권한을 실현하는 방법은 무엇입니까?"라는 질문을 자주 받습니다.

그러한 요구 뒤에는 개발자가 일부 데이터를 체인에 넣고 스마트 계약이 이를 관리하고 계산하여 비즈니스 합의에 도달하기를 원하지만 체인의 다른 무단 참가자를 피하기 위해 데이터가 공개적으로 표시되는 것을 원하지 않습니다. 정보를 제공합니다.

가장 직관적인 구현 아이디어는 데이터 반환을 허용하기 전에 호출자가 특정 조건(예: 화이트리스트에 있음)을 충족하는지 판단하고, 그렇지 않으면 데이터를 거부하는 필터링 논리를 계약 코드에 작성하는 것입니다.

우리는 사례를 설정했습니다: 포인트 동맹 체인이 있고 체인의 참가자는 Alice, Bob, Carl, Dave 등 및 그들의 가족을 포함합니다.각 개인의 포인트 잔액은 다음과 같이 설정될 수 있기를 바랍니다. 자신과 가족에게 표시되며 다른 참가자에게는 표시되지 않습니다. .

클라이언트는 블록체인의 애플리케이션 수준 인터페이스를 통해 특정 노드에 요청을 보내고 스마트 계약의 get 메소드를 호출하여 Bob의 포인트를 확인하고 스마트 계약은 권한 제어 논리를 작성하여 무단 액세스를 거부합니다.

각 노드에서 실행되는 스마트 컨트랙트의 로직은 일관성이 있기 때문에 어떤 노드로 요청을 보내도 결과는 동일합니다. 이것은 좋은 생각처럼 보일 수 있지만 실제로 그럴까요?

먼저 결론은 다음과 같습니다. 이것은 "영구적이지 않은 완화적" 접근 방식이며 데이터가 유출되지 않는다는 보장은 없습니다.

이제부터는 "멀티 센터 및 무신뢰"라는 생각으로 이 사건을 재검토할 것입니다.

먼저 분석해 보겠습니다. 데이터가 체인에 어떻게 저장되어 있습니까? 어떤 상황에서 유출되나요?

블록체인 네트워크 노드는 다양한 참가자의 환경에 분산되어 있으며 블록체인의 데이터 일관성 특성으로 인해 각 노드는 데이터의 완전한 사본을 보유합니다. 데이터베이스가 LevelDB/RocksDB와 같은 파일 유형 데이터베이스인지 Mysql과 같은 관계형 데이터베이스인지에 관계없이 데이터는 각 노드의 데이터베이스 인스턴스에 속합니다.

즉, Bob의 포인트 잔액은 모든 노드의 하드 디스크에 저장되며 MySQL 데이터베이스 도구에서 보면 다음과 같습니다.

체인에 블록체인 기술에 약간의 경험이 있고(작은 확률로) 비밀리에 "악의성"(Byzantine 플레이어라고도 함)을 품고 있는 참가자가 있는 경우 그는 도구를 사용하여 로컬 데이터베이스를 열고 Bob의 잔액을 직접 쿼리할 수 있습니다. 이러한 방식으로 데이터 유출을 방지하기 위해 계약을 사용하는 제어 논리가 완전히 우회됩니다. 그렇게 간단합니다.

또한 블록체인 데이터는 계약뿐만 아니라 트랜잭션 기록과도 밀접한 관련이 있습니다.

트랜잭션을 보낼 때 트랜잭션 매개 변수에는 데이터의 일부 또는 전부가 포함되며(예: Alice는 100을 Bob에게 전송) 트랜잭션은 블록으로 패키지되고 최종적으로 노드 데이터베이스에 기록됩니다.

블록 및 트랜잭션 데이터에 대한 쿼리는 일반적으로 계약 논리로 구현되지 않으므로 계약에 필터링 논리를 작성하는 것만으로는 이러한 데이터 읽기를 막을 수 없습니다. Byzantine 플레이어는 로컬 데이터베이스의 블록 데이터를 탐색하고 트랜잭션 내역 세부 정보를 얻고 처음부터 끝까지 트랜잭션 흐름을 재생하고 Bob의 현재 잔액이 300임을 알 수 있습니다.

전체 기술 스택의 관점에서 비잔틴 플레이어가 도구를 사용하여 로컬 데이터에 액세스하고 블록을 통과하고 거래하는 것은 사소한 일이며 블록체인 네트워크 인터페이스, 프로그램 측면에서 블록체인 시스템의 코드를 수정할 수도 있습니다. 메모리 및 스마트 계약 엔진 프로토콜 패키지, 블록, 트랜잭션 흐름, 계약 컨텍스트, 상태 데이터 등에서 일반 텍스트 데이터를 잘라내고 스니핑하고 가로채기 데이터가 암호화되고 키가 노드 소유자의 손에 있더라도 그는 여전히 잠금을 해제할 수 있습니다.

따라서 블록체인의 기본 코드에서 시작하여 데이터 읽기 권한을 제어하는 ​​것도 쓸모가 없습니다.결국 누구나 오픈 소스 코드를 변경할 수 있습니다.중국의 "악당"은 전능하고 경계하기 어렵습니다.

결론적으로 블록체인은 강조한다.그리고그리고"일관성", 일반 텍스트 데이터가 체인에서 브로드캐스트되는 한 다른 사람들이 이를 얻을 수 있는 방법은 무수히 많습니다. 계약 계층에 있든 기본 코드에 있든 거의 모든 읽기 제어 논리는 다음과 같습니다.창호지찌르고 부수듯이마지노선같은 것은 쓸모가 없습니다.

이것을 보고 누군가는 다음과 같이 질문할 수 있습니다. 데이터 읽기가 너무 무방비 상태라면 블록체인에 대한 "쓰기" 권한이 여전히 의미가 있습니까? 대답은: 예입니다.

포인트의 예로 돌아가서 Alice를 포인트 관리자로 설정하여 그녀가 포인트 전송 트랜잭션을 시작할 수 있도록 한 다음 Bob은 Alice의 포인트만 수락합니다. 포인트 이전 거래는 전체 네트워크의 합의를 거쳐야 하며, 모든 합의 노드는 계약에 명시된 규칙을 확인하고 요구 사항을 충족하지 않는 경우 서명을 거부합니다.권한을 넘어선 거래에 동의할 수 없는 경우, 데이터는 수정되지 않습니다.

이때 소수의 Byzantine 노드가 있더라도 로컬 노드가 아무리 어려워도 전체 네트워크의 데이터를 변조할 수 없습니다.

합의를 추구하는 "쓰기" 트랜잭션, 따라서 클라이언트가 트랜잭션(sendTransaction 또는 sendRawTransaction)을 보낼 때 디지털 서명이 있어야 하며 블록체인 시스템은 서명을 확인하여 트랜잭션을 보낸 외부 계정을 확인하므로 엄격하게 확인되고 정확하게 추적될 수 있습니다.

"읽기" 작업은 공유에 더 중점을 둡니다., 데이터 읽기 작업은 실제로 합의 프로세스를 거치지 않고 자신의 노드에서 데이터를 넘기기만 하면 됩니다. 일반적으로 블록체인 시스템은 읽기 인터페이스(호출)에서 보낸 사람을 엄격하게 입력할 필요가 없으며 디지털 서명을 할 필요가 없으므로 계약 읽기 방식에서 외부 계정을 판단하는 것은 유효하지 않습니다.

위의 분석을 바탕으로 체인에 읽기 제어를 구현하는 것이 간단한 문제가 아니라는 결론을 내릴 수 있습니다.

읽기 제어 논리에 대한 고려가 충분하지 않은 경우 결과는 다음과 같습니다: 자신의 노드에서 데이터를 읽고 테스트 및 확인하고 모양이 괜찮아 보입니다.년이 조용하다고 생각하지만 데이터가 비잔틴 플레이어에 의해 뒤집혔습니다. 바닥이 위입니다.

다자간 협력의 탈신뢰와 데이터 공유, 개방성 및 투명성 추구를 고려할 때 일반적으로 말해서 유출될 수 없는 중요하고 민감한 데이터인 경우 조심스럽게 체인에 업로드해야 합니다. 공통 약수"를 공유할 수 있습니다.

실제로 많은 블록체인 시스템의 거래 및 잔액 상태는 전체 네트워크에서 볼 수 있습니다.소위 익명성 또는 프라이버시는 일반 텍스트 계정을 대체하기 위해 공개 및 개인 키와 주소 시스템만 사용합니다.금융과 같은 분야에는 적합하지 않습니다. 모델이 복잡하고 포괄적인 프라이버시가 강조되는 정부 업무.

그렇다면 공유, 투명성, 개방성을 고려하면서 데이터 가시성을 적절하게 제어하기 위한 다른 방법은 무엇일까요?

첫 번째 아이디어는오프체인 거버넌스와 결합, 책임과 권리의 경계에 동의합니다. 계약 및 인터페이스 수준에서 권한의 설계 및 구현을 잘 수행하여 내 비즈니스 시스템에서 데이터가 유출되지 않도록 하고 내 블록체인 애플리케이션 계층, 디스플레이 인터페이스, 보고서, 로그, 데이터베이스 및 기타 링크가 유출되지 않도록 합니다. 권한이 없는 사람이 액세스할 수 있으므로 내부적으로 위험을 관리할 수 있습니다.

다른 사람의 노드에 관해서는 신경 쓰지 않습니다. 그것은 그들의 책임입니다. 데이터를 유출하고 오용하는 사람은 엄중히 처벌됩니다 (실제로 증거를 얻기가 어렵습니다). 이런 종류의 논리는 실제로 "모든 사람보다 먼저 눈을 치우다"를 의미합니다. 이 모드에서는 여전히 내 민감한 데이터를 다른 사람에게 업로드할 수 없습니다.

두 번째 아이디어는암호학 소개. 다음은 몇 가지 예입니다.

비대칭 암호화:체인의 데이터는 수신자의 공개 키로 암호화되며 수신자만이 자신의 개인 키로 잠금을 해제할 수 있습니다.

암호 봉투:업링크 데이터는 일정한 비밀번호로 암호화되며, 비밀번호는 오프체인 채널을 통해 수신자에게 부여되며, 비밀번호를 아는 수신자만이 복호화할 수 있습니다.

속성 암호화:데이터는 속성 암호화 알고리즘을 사용하여 암호화되며 지정된 속성(예: 관리자 속성)을 충족하는 데이터만 복호화할 수 있습니다. 이러한 솔루션의 고려 사항은 계산, 전송 및 저장의 오버헤드가 더 높을 것이라는 점과 암호화된 데이터가 일반 텍스트 계산을 지원하지 않아 복잡한 비즈니스 계약 논리를 구현하기 어렵다는 것입니다. 또한 암호화된 경우에도 기본적으로 데이터의 모든 정보는 여전히 체인에 있으며, 시간이 지남에 따라 컴퓨팅 성능과 알고리즘(예: 양자 암호)의 진화에 따라 다음과 같은 가능성이 있습니다. 무차별 대입, 또는 키가 유출/너무 쉽게 추측되어 체인의 데이터를 인출할 수 없는 경우 세상에 알려질 위험이 있습니다.

세 번째 아이디어는요약만 체인에 업로드됩니다., 데이터 일반 ​​텍스트가 체인에 전혀 없습니다.

사실 블록체인의 역할은 데이터를 완전히 파악하고 복잡한 비즈니스 규칙을 실행하는 것이 아니라 여러 증인의 신뢰성에 의존하여 데이터의 정확성과 무결성을 확인하고 증거 및 추적 기능을 수행하는 것입니다. 이 단계에서 많은 블록체인 시스템은 주로 그러한 논리를 기반으로 하며, 이는 객관적으로 신뢰의 앵커 포인트 역할을 할 수 있습니다.

일반 텍스트 데이터가 필요한 경우 초록의 주소 지정 정보를 사용하여 오프체인 시스템에서 데이터를 가져오고 이 링크에서 세분화된 권한 제어를 수행하고 온체인 초록과 상호 검증을 수행합니다.

그러나 데이터가 체인에 있지 않다는 점은 여전히 ​​약간의 조화가 있습니다.이 혁신적인 블록 체인 개념과 스마트 계약의 강력한 기능을 어떻게 완전히 활용할 수 있습니까?

그것은 관하여프라이버시 컴퓨팅영지식 증명, 준동형 암호화, 안전한 다자간 컴퓨팅 및 연합 학습을 포함하되 이에 국한되지 않는 일련의 중화기는 덧셈, 뺄셈, 곱셈, 나눗셈, 논리 연산, 정렬 및 통계 분석을 수행할 수 있습니다. 규정 준수 요구 사항을 충족하기 위해 "익명 프론트 데스크 및 감사 가능한 배경"의 효과. 이것이 블록체인에서 "보이지 않는 사용 가능"의 궁극적인 의미입니다.

공간 제한으로 인해 개인 정보 계산의 세부 사항은 여기에서 논의되지 않습니다.WeDPR 개인 정보 보호와 관련된 오픈 소스 시나리오 솔루션, 특히 VCL 블록체인 검증 가능한 암호문 원장과 같은 여러 시나리오를 참조하여 문제를 해결하는 데 사용할 수 있습니다. 위에서 언급한 포인트 케이스의 일부 개인 정보 보호 문제.

WeDPR 개인 정보 보호 관련 오픈 소스 시나리오 솔루션:

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

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

발문

원래는 "계약서 읽기 권한 작성 방법"과 같은 작은 문제에 대해 이야기하고 싶었지만 긴 기사가되었습니다.

사실 블록체인 프로그래밍 및 개발에 직면할 때 독립 실행형 또는 클러스터 소프트웨어 작성과 같은 문제에 대해 생각할 수 없으며 공유의 기본 철학을 기반으로 다자간 참여 및 신뢰가 필요 없는 환경에서 협업 관계를 충분히 고려합니다. , 투명성 및 추적 가능성 먼저 개인 정보 보호 호소에 주의를 기울이고 데이터의 중요성과 민감도를 평가한 다음 기술 스택에 깊이 들어가 다양한 알고리즘의 효율성과 비용을 고려하고 현재와 미래의 위험과 이점을 결합하여 데이터와 개인 정보를 완전히 보호하고 사업을 안전하게 발전시키며 회사와 사용자의 권리와 이익을 보호하기 위해 적절한 전략을 선택합니다.