FHE는 a16z가 제기한 규정 준수 가능한 프로그래머블 프라이버시 문제를 어떻게 해결하나요?

原文标题：《프로그래머블 프라이버시와 동시 준수를 위한 동형 암호화》

저자：Rand Hindi

편집：Luccy，BlockBeats

편집자의 말：

9월 19일, a16z의 암호화 팀은 나카모토 챌린지에서 7가지 질문을 제기했습니다. 질문은 다음과 같습니다: 원자적 조합성과 공유 순서의 한계, DePIN 검증, JOLT + Lasso 문제, 준수 가능한 프로그래머블 프라이버시, 최적의 LVR 완화, MEV 거래 공급망 설계 및 블록체인을 이용한 딥페이크 보호.

준수 가능한 프로그래머블 프라이버시 문제에 대해, 오픈 소스 암호화 도구 Zama는 완전 동형 암호화(FHE) 또는 fhEVM 기밀 스마트 계약 프로토콜을 제안했습니다. fhEVM은 암호화된 상태에서 계산을 수행할 수 있는 능력으로 개발자에게 체인 상에서 준수 가능한 프로그래머블 프라이버시 애플리케이션을 구축할 수 있는 새로운 경로를 제공합니다.

탈중앙화 신원(DID)은 디지털 신원의 발급자로, 암호화된 상태에 저장되어 사용자 신원의 프라이버시와 프로그래머블 준수의 윈-윈을 실현합니다. 규제 계약을 통해 개인 간의 토큰 전송 규칙을 정의하여 전송 조건에 대한 동적 규제를 실현합니다. 이 설계는 스마트 계약 수준에서 규제 규정을 실행하며, 하드 코딩이 필요 없고, 사용자는 몇 줄의 Solidity 코드로 애플리케이션의 준수를 보장할 수 있습니다.

Zama의 CEO Rand Hindi는 기사에서 fhEVM을 사용하여 준수 가능한 ERC20 토큰을 구축하는 방법을 보여주며, 체인 상의 DID를 통해 신원 추상화를 수행합니다. 그는 다른 프라이버시 솔루션에 비해 fhEVM의 모든 데이터와 계산이 체인 상에서 발생하여 조합성과 데이터 가용성을 보장한다고 강조합니다.

몇 달 전, a16z의 암호화 팀은 나카모토 챌린지(중본 챌린지)를 발표했습니다. 이는 블록체인에서 해결해야 할 가장 중요한 문제 목록입니다. 그 중 네 번째 문제는 특히 우리의 주목을 끌었습니다: "준수 가능한 프로그래머블 프라이버시"입니다. 우리는 이 문제에 대해 적극적으로 고민해 왔으며, 오늘 우리는 동형 암호화와 fhEVM 기밀 스마트 계약 프로토콜을 사용하는 첫 번째 솔루션을 제안합니다.

fhEVM은 몇 가지 precompiles을 포함한 일반 EVM으로, 우리의 TFHE-rs 동형 암호화 라이브러리를 사용하여 암호화된 상태에서 계산을 수행할 수 있습니다. 개발자의 관점에서 볼 때, 암호학이 포함되지 않으며, 그들은 우리가 제공하는 암호화 데이터 유형(euint32, ebool 등)을 사용하여 Solidity 코드를 작성하기만 하면 됩니다. fhEVM의 다른 프라이버시 솔루션에 대한 주요 이점은 모든 데이터와 계산이 체인 상에서 발생한다는 것입니다. 이는 일반 명문 계약과 동일한 조합성과 데이터 가용성을 얻을 수 있음을 의미합니다.

이 기능은 프로그래머블 프라이버시를 구축하는 데 필수적입니다. 모든 접근 제어 논리는 계약 자체에서 정의될 수 있습니다. 프로토콜 내에는 하드 코딩해야 할 내용이 없으며, 사용자는 준수를 보장하기 위해 체인 외부에서 어떤 작업도 수행할 필요가 없습니다. 애플리케이션은 몇 줄의 Solidity 코드로 직접 준수를 강제할 수 있습니다.

이 기사에서는 체인 상의 DID를 사용하여 준수 가능한 ERC20 토큰을 구축하는 방법을 보여줍니다. 본 튜토리얼의 소스 코드는 fhEVM 저장소의 examples 폴더에서 확인할 수 있습니다.

체인 상의 기밀 DID를 통한 신원 추상화

탈중앙화 신원(DID)은 정부, 등록 기관, 회사 또는 사용자 자신과 같은 실체에 의해 발급된 고유한 디지털 신원입니다. 이 DID는 사용자가 DID를 소유하고 있음을 증명하는 암호화 키와 결합될 수 있으며, 예를 들어 EVM 지갑과 연결될 수 있습니다. 그러나 사용자의 나이, 국적, 사회 보장 번호와 같은 다양한 속성을 저장할 수도 있습니다. 이러한 속성은 특정 조건(예: 18세 이상이거나 나니아 시민이 아님)을 충족하는지 증명하는 데 사용될 수 있습니다. 정부, 등록 기관, 회사 또는 사용자 자신과 같은 실체에 의해 발급됩니다.

대부분의 DID는 실제로 사용자 측에서 구현되며, 제로 지식 증명을 사용하여 증명을 생성합니다. 많은 경우에 이것은 가능하지만, 여러 사용자가 거래에 참여하거나 DID에 복잡한 규칙을 적용해야 하거나 모두가 공통 규칙을 따라야 할 경우 상황이 복잡해질 수 있습니다. 이는 본질적으로 엣지 애플리케이션과 클라우드 애플리케이션 간의 균형과 유사합니다.

그러나 중앙 집중식 DID 레지스트리를 보유하면 이러한 문제를 해결할 수 있습니다. 레지스트리에 각 개인이 규정을 준수하는지 확인하도록 요청할 수 있기 때문입니다. 이는 규제 추적을 더 간편하게 만들어줍니다. 한 곳에서만 시행하면 되기 때문입니다. 블록체인은 DID와 규정을 준수해야 하는 애플리케이션 간의 조합성과 규정 간의 조합성을 허용하기 때문에 이상적인 인프라가 될 것입니다. 이는 본질적으로 엣지 애플리케이션과 클라우드 애플리케이션 간의 균형과 유사합니다.

문제: 모든 사람이 모든 사람의 신원을 볼 수 있습니다!

다행히도 우리는 해결책이 있습니다: 동형 암호화, 더 구체적으로는 fhEVM입니다! 암호화된 상태에서 조합성을 갖추고 있기 때문에, 우리는 사용자 DID를 암호화된 형태로 체인 상에 직접 호스팅할 수 있으며, 간단한 계약 호출을 통해 준수 가능한 애플리케이션이 속성을 검증할 수 있습니다. 신원을 관리하는 능력을 우리는 "신원 추상화"라고 부르며, 이는 계좌 추상화를 통해 자금을 관리하는 방식과 유사합니다.

본 튜토리얼은 3개의 부분으로 나뉩니다:

신원 추상화는 신원과 증명을 관리하는 등록 계약을 통해 구현됩니다. 여기서 우리는 DIDs가 공식 정부 신분증이라고 가정합니다. 레지스트리는 중앙 기관(예: AFNIC)에 의해 관리되며, 이 기관은 등록 기관(예: KYC 회사, Onfido, Jumio 등)을 생성할 수 있습니다. 그런 다음 등록 기관은 사용자 DID를 생성할 수 있습니다. 사용자는 자신의 등록 기관을 통해 DID를 관리하고 업데이트합니다.

규제는 계약 내에서 정의되며, 이는 사용자 DID에 포함된 정보에 기반하여 개인 간의 토큰 전송 규칙을 인코딩합니다. 이는 기본적으로 계약 수준에서 실행됩니다.

준수 가능한 기밀 전송은 준수 가능한 ERC20 계약 내에서 구현되며, 이 계약은 규제 계약을 사용하여 토큰 전송의 준수를 강제합니다. ERC20 API 자체에 대한 변경 없이 이루어집니다. 이 예제에서는 잔액과 금액이 숨겨진 기밀 ERC20 계약을 사용하지만, 일반 명문 ERC20 토큰에도 동일하게 적용됩니다.

신원 등록 계약

신원 등록 계약은 등록 기관이 사용자 DID를 발급하는 레지스트리로, 국적, 나이, 사회 보장 번호 등과 같은 암호화된 식별 세트를 포함합니다. 이러한 식별자는 암호화된 32비트 값(euint32) 형태로 저장됩니다.

이 계약은 권한도 처리합니다. 여기에는 다음이 포함됩니다:

계약 소유자(예: AFNIC)가 등록 기관을 추가, 삭제 또는 업데이트할 수 있도록 허용합니다.

등록 기관이 자신이 생성한 사용자 DID를 추가, 삭제 또는 업데이트할 수 있도록 허용합니다.

사용자가 스마트 계약에 특정 속성에 대한 DID 접근 권한을 부여할 수 있도록 허용합니다. 여기서 사용자는 악의적인 계약에 접근 권한을 부여하지 않을 책임이 있으며, 이는 그들이 악의적인 계약이 자신의 토큰을 사용하지 못하도록 하는 것과 같습니다.

첫 번째 단계는 DID를 생성하고 관리하는 로직을 구현하는 것입니다:

참고: 이미지는 일부 스크린샷이며, 원문에서 전체 코드를 확인할 수 있습니다.

다음 단계는 식별 및 접근 제어 로직을 구현하는 것입니다.

식별자는 간단히 말해 문자열(예: "생년월일")과 암호화된 32비트 값입니다. 이는 등록 기관만 생성하거나 업데이트할 수 있습니다. 사용자는 자신의 식별자를 생성할 수 없으며, 이는 등록 기관의 인증을 거쳐야 하기 때문입니다.

그러나 식별자가 암호화되어 있기 때문에 사용자는 계약에 특정 값에 대한 접근 권한을 부여해야 하며, 우리는 이를 간단한 접근 제어 메커니즘을 통해 처리할 것입니다. 이는 사용자가 계약이 자신의 ERC20 토큰을 사용할 수 있도록 허용하는 간단한 접근 제어 메커니즘과 유사합니다.

참고: 이미지는 일부 스크린샷이며, 원문에서 전체 코드를 확인할 수 있습니다.

이제 필요한 getter를 추가하고 몇 가지 조건과 오류 처리를 통해 우리의 신원 등록 계약을 완성할 수 있습니다.

참고: 이미지는 일부 스크린샷이며, 원문에서 전체 코드를 확인할 수 있습니다.

규제 계약

다음 단계는 규제 계약을 만드는 것입니다.

두 개인 간의 전송 규칙을 구현할 때, 이러한 규칙이 시간이 지남에 따라 진화할 수 있다는 점을 인식하는 것이 중요합니다. 특정 맥락(예: 자금 이동)에 대한 모든 규제 규정을 정의하는 단일 스마트 계약이 있으면, ERC20 계약은 스스로 규제 규정을 추적할 필요가 없습니다. 정부는 이 계약을 업데이트하기만 하면 되며, 그러면 이 계약을 시행한 모든 토큰에 자동으로 전파됩니다.

핵심적으로, 규제 계약은 암호화된 신원 속성과 일치하는 조건의 집합일 뿐입니다. 남용을 방지하기 위해 사용자는 규제 계약에 직접 접근 권한을 부여하지 않고, 대신 ERC20 토큰 계약에 접근 권한을 부여하며, ERC20 토큰 계약이 규제 계약에 대한 위임 호출을 수행합니다. 이 방법은 사용자가 신뢰하는 ERC20 계약만이 그들의 정보에 접근할 수 있도록 보장합니다. 발신자와 수신자 간의 전송이 발생하기 전에, 그들은 모두 ERC20 계약에 권한을 부여해야 합니다.

이 예제에서는 몇 가지 기본 규칙을 구현할 것입니다:

국내 전송은 제한이 없지만, 외국으로의 전송 한도는 1만 토큰입니다.

블랙리스트 사용자에게는 토큰을 전송하거나 수신할 수 없습니다.

사용자는 블랙리스트 국가로 토큰을 전송할 수 없습니다.

거래가 실패하는 것보다 민감한 정보가 유출될 가능성이 있는 경우, 조건이 충족되지 않으면 전송 금액을 0으로 설정합니다. 이는 cmux라는 동형 삼원 연산자를 사용합니다: value = TFHE.cmux(encryptedCondition, valueIfTrue, valueIfFalse);

참고: 이미지는 일부 스크린샷이며, 원문에서 전체 코드를 확인할 수 있습니다.

준수 가능한 프라이버시 ERC20 계약

이제 우리는 신원 등록 및 규제 계약을 갖추었으므로, 요구 사항을 충족하고 프라이버시를 보호하는 토큰 계약을 생성할 수 있습니다. 이 계약은 CompliantERC20이라고 불리며, 다음과 같은 주요 특징을 가지고 있습니다:

사용자 잔액과 전송 금액은 모두 암호화되어 있습니다.

준수는 규제 계약을 호출하여 전송을 실행합니다.

화이트리스트 주소(예: 규제 기관)에 특정 잔액에 대한 가시성을 부여할 수 있습니다.

규제 계약을 간단히 호출할 수 있습니다. 이는 사용자가 어떤 전송을 시작하기 전에 ERC20 계약에 대한 접근 권한을 제공해야 함을 의미합니다. 그렇지 않으면 전송이 롤백됩니다.

마지막으로, 이제 우리는 우리의 ERC20 계약을 생성할 수 있습니다:

사용자가 DeFi 프로토콜에 자신의 토큰을 사용할 수 있는 권한을 부여하는 것과 유사하게, 그들은 계약이 규제 계약에 필요한 식별자에 접근할 수 있는 권한을 부여해야 합니다. 이는 Identity.grantAccess(contractAddress, identifiers)를 호출하여 이루어지며, ERC20.identifiers() 뷰 메서드를 호출하여 검색할 수 있습니다. 이 목록은 속성의 업데이트를 허용하기 위해 ERC20Rules 계약에서 직접 가져옵니다.

준수와 프라이버시는 공존할 수 있다

적절한 도구가 있다면, 준수를 구축하는 것은 어렵지 않습니다. 우리는 처음에 블록체인에서 프라이버시를 구현하기 위해 fhEVM을 구축했지만, 이 기술이 신원 관리에 사용될 수 있음을 곧 깨달았습니다. 이를 통해 프로그래머블 준수를 실현할 수 있습니다.

이 설계는 아직 완벽하지 않지만, 우리는 그것이 계속 개선될 수 있으며, 준수가 더 이상 규제와 동일시되지 않는 실제 사용 사례로 출시될 수 있다고 믿습니다.