기밀 지급 개요

Oracle Blockchain Platform Digital Assets Edition은 Pedersen의 약정을 사용하여 데이터를 안전하게 보호합니다.

지식이 없는 검증

ZKP(Zero-Knowledge Proofs)는 정직한 발언자가 추가 정보를 공개하지 않고 검증자에게 진술의 진실을 보여줄 수 있는 암호화 프로토콜입니다. 부정직한 속담은 거짓 진술이 참이라는 검증자를 설득할 수 없습니다. ZKP는 청구의 유효성 이상으로 민감한 데이터가 공개되지 않도록 보장합니다. ZKP는 값 자체를 공개하지 않고 범위 내에 속하거나 특정 계산의 결과인지 확인하는 등 비밀 값의 특정 속성을 증명할 수 있도록 합니다.

페더슨 약정

영지식 증명은 약정 체계에 따라 달라지며, 이 체계에서는 누군가가 특정 값을 커밋하면서 다른 사람에게 숨길 수 있습니다. Oracle Blockchain Platform Digital Assets Edition은 페더슨의 약정을 사용합니다. 페더슨 약정은 타원 곡선 암호화와 함께 분사 계수로 알려진 임의 값을 사용하여 비밀성과 불변성을 모두 보장합니다. 페더슨 약정은 형태적입니다. 즉, 기본 값 간의 관계를 유지하면서 약정에 대한 추가 및 빼기와 같은 수학적 작업을 수행할 수 있도록 지원합니다. 페더슨 약정은 개인 트랜잭션 프로토콜, 보안 다자간 계산 및 익명 자격 증명 시스템에서 사용됩니다.

기밀 지불 작업

트랜잭션 요청에서 Confidential-Transaction 헤더를 사용하여 기밀 지급 기능을 활성화합니다.

요청에서 Confidential-Transaction 헤더를 true로 전송하면 Oracle Blockchain Platform의 REST 프록시가 고유한 난수(페더슨 약정에 필요한 블라인딩 계수)를 생성하고 임시 맵에 전달합니다. 이는 체인코드가 입력을 처리하고 상태 데이터베이스가 아닌 개인 데이터 수집에 중요한 정보를 저장하는 데 사용됩니다.

트랜잭션 정보

모든 토큰 작업(계정 생성, 마이팅, 전송, 레코딩 등)은 트랜잭션 기록을 추적할 수 있도록 트랜잭션 레코드를 생성합니다. 트랜잭션 데이터는 공용 원장(상태 데이터베이스)과 전용 데이터 수집의 두 위치에 저장됩니다. 기밀 지급을 통해 중요한 데이터는 트랜잭션과 관련된 조직의 개인 데이터 수집에만 일반 텍스트로 저장됩니다. 다음 테이블에서는 지정된 트랜잭션 ID에 대한 트랜잭션 값이 저장되는 위치를 보여줍니다.

Public Ledger(상태 데이터베이스) 개인 데이터 수집

Public Ledger(상태 데이터베이스)	개인 데이터 수집
`assetType` `transaction_id` `token_id` `from_account_id` `from_account_balance (encrypted)` `from_account_onhold_balance (encrypted)` `from_account_onhold_burn_balance (encrypted)` `to_account_id` `to_account_balance (encrypted)` `to_account_onhold_balance: (encrypted)` `to_account_onhold_burn_balance (encrypted)` `transaction_type` `amount`(암호화됨) `timestamp` `number_of_sub_transactions` `holding_id` `sub_transaction` `sub_transaction_type` `category` `description` `global_transaction_id`	`assetType` `transaction_id` `from_account_balance` `from_account_onhold_balance` `from_account_onhold_burn_balance` `to_account_balance` `to_account_onhold_balance` `to_account_onhold_burn_balance` `amount` `blindingFactor` `version`

assetType
transaction_id
token_id
from_account_id
from_account_balance (encrypted)
from_account_onhold_balance (encrypted)
from_account_onhold_burn_balance (encrypted)
to_account_id
to_account_balance (encrypted)
to_account_onhold_balance: (encrypted)
to_account_onhold_burn_balance (encrypted)
transaction_type
amount(암호화됨)
timestamp
number_of_sub_transactions
holding_id
sub_transaction
sub_transaction_type
category
description
global_transaction_id

assetType
transaction_id
from_account_balance
from_account_onhold_balance
from_account_onhold_burn_balance
to_account_balance
to_account_onhold_balance
to_account_onhold_burn_balance
amount
blindingFactor
version

토큰 계정 정보

마찬가지로 토큰 계정에 대한 정보는 공개 원장 및 개인 데이터 수집에 저장됩니다. 다음 테이블에서는 지정된 토큰 계정 ID에 대한 트랜잭션 값이 저장되는 위치를 보여줍니다.

Public Ledger(상태 데이터베이스)	개인 데이터 수집
`assetType` `account_id` `org_id` `token_type` `token_id` `token_name` `balance`(암호화됨) `onhold_balance`(암호화됨) `onhold_burn_balance`(암호화됨) `application_groups` `bapAccountVersion`	`assetType` `account_id` `user_id` `balance` `onhold_balance` `onhold_burn_balance` `balanceBlindingFactor` `onHoldBalanceBlindingFactor` `onHoldBurnBalanceBlindingFactor` `max_daily_amount` `daily_amount` `max_daily_transactions` `daily_transactions` `current_date`

다음 데이터가 공공 원장에 저장됩니다.

account_id 키 - 시스템의 모든 사용자에 대해 고유합니다. 일반적으로 다른 접두어 또는 접미어와 결합된 orgId(MSP ID) 및 userId(사용자 이름 또는 전자메일)의 SHA-256 해시입니다.
공용 원장은 모든 사용자의 모든 계정 키를 저장합니다. 사용자는 각 토큰에 대해 하나씩 여러 개의 대체 가능한 토큰 계정을 가질 수 있습니다.
토큰 세부정보는 token_type, token_id 및 token_name 필드에 저장됩니다.
balance 및 onhold_balance 필드에는 개인 데이터 수집에 저장된 잔액의 실제 텍스트 값을 나타내는 페더슨 약정 해시가 포함됩니다.

다음 데이터는 개인 데이터 수집에 저장됩니다.

앞에서 설명한 account_id 키입니다.
balance 및 onhold_balance 필드에는 해당 잔액의 실제 텍스트 값이 포함됩니다.
balance_blinding_factor 및 on_hold_balance_blinding_factor 필드는 공용 원장에 저장된 balance 및 onhold_balance 약정을 생성하는 데 사용되는 임의 키를 저장합니다.
일일 거래 세부 정보는 max_daily_amount, daily_amount, max_daily_transactions, daily_transactions 및 current_date 필드에 저장됩니다.

기밀 지급이 있는 일반적인 작업

기밀 결제를 사용하는 동안 토큰을 민트, 전송, 보류 또는 구울 때의 워크플로우에는 데이터 무결성을 보장하기 위한 추가 단계가 포함됩니다.

Minting 토큰

토큰을 민트하기 위해 minter 롤을 가진 사용자가 issueTokens API를 호출합니다.

기밀 지급 사례에서 issueTokens 메소드는 token_id 값을 입력으로 사용하고 임시 맵에 전달된 토큰 수량과 함께 REST 프록시에서 전송되는 블라인딩 계수가 필요합니다.
확인 후 Pedersen 약정은 블라인딩 계수 및 민트에 대한 토큰 수량에서 생성됩니다.
그런 다음 전체 수량이 공용 원장과 개인 데이터 수집 모두에서 업데이트됩니다. 공공 원장에서 기존 잔액을 나타내는 페더슨 약정은 주조된 토큰의 수량을 나타내는 페더슨 약정으로 증가합니다(발행). 개인 데이터 수집에 저장된 잔액의 실제 값이 그에 따라 증가합니다.
블라인딩 계수도 업데이트되므로 언제든지 개인 데이터 수집의 잔액 및 블라인딩 계수를 사용하여 공공 원장에 저장된 해당 약정을 확인할 수 있습니다.

조직 내에서 토큰 전송

조직 내에서 토큰을 전송하기 위해 발신자는 transferTokens API를 호출합니다.

기밀 지급 사례에서 transferTokens 메소드는 token_id 및 선택적 매개변수를 입력으로 사용하며 수신자에 대한 userId 및 orgId 값 및 임시 맵에 전달된 토큰 수량과 함께 REST 프록시에서 전송되는 블라인딩 계수가 필요합니다.
확인 후 Pedersen 약정은 블라인딩 계수 및 전송할 토큰 수량에서 생성됩니다.
발신자 계정의 토큰 수량이 감소하고 수신자 계정의 수량이 퍼블릭 원장과 프라이빗 데이터 수집 모두에서 증가합니다. 공공 원장에서 발신자의 기존 잔액을 나타내는 페더슨 약정은 토큰 이전자의 수량을 나타내는 페더슨 약정에 의해 감소됩니다. 수신기의 경우 잔액이 동일한 방식으로 증가합니다. 발신자 잔액 및 수신자 잔액의 실제 값이 개인 데이터 수집에서 업데이트됩니다.
블라인딩 계수도 업데이트되므로 언제든지 개인 데이터 수집의 잔액 및 블라인딩 계수를 사용하여 공공 원장에 저장된 해당 약정을 확인할 수 있습니다.

조직 간 토큰 전송

조직 간에 토큰을 전송하기 위해 발신자는 holdTokens API를 호출하여 전송 금액을 추출하고 보류합니다.

기밀 지급 사례에서 holdTokens 메소드는 token_id, operation_id 및 expiration_time 값을 입력으로 사용하며 notary_user_id, notary_org_id, to_user_id 및 to_org_id 값과 임시 맵에 전달된 토큰 수량과 함께 REST 프록시에서 전송되는 블라인딩 계수가 필요합니다.
확인 후 Pedersen 약정은 블라인딩 계수 및 보유할 토큰 수량에서 생성됩니다.
보류 객체 및 발신자 객체가 생성됩니다.
잔액 약정, 실제 잔액 및 트랜잭션 객체는 두 조직의 공용 원장 및 개인 데이터 수집에 저장되며 이에 따라 모든 잔액이 업데이트됩니다.

보유 토큰

앞서 언급했듯이 보류 작업은 조직 간에 토큰을 이전하는 데 사용됩니다. 보류 작업은 공개 원장 및 개인 데이터 수집 모두에 데이터를 저장하는 트랜잭션 및 토큰 계정 객체와 유사한 보류, 발신자 및 수신자 객체를 사용합니다. 보류 작업은 동일한 조직의 전송에 사용될 수도 있습니다. 이 경우 발신자 및 수신자 객체가 생성되지 않으며 페더슨 약정을 사용하는 일반 토큰 분류법 프레임워크 작업으로 이전이 발생합니다. 다음 테이블에서는 지정된 보류 트랜잭션 ID에 대한 트랜잭션 값이 저장되는 위치를 보여 줍니다.

기밀 모드에서는 조직 간 전송에는 두 개의 개인 데이터 수집이 포함됩니다. 계정 키/값 쌍을 수정하는 대신 차변에 대해 보류 작업 중 발신자 객체가 생성되고 대변에 대해 수신자 객체가 생성됩니다(executeHoldReceiver API 실행 시). 잔액이 발신자 객체에 배치됩니다. 대변 기입된 금액은 수신자에게 지정된 수신자 객체에 지정됩니다. 차변 작업이 완료되면 발신자 객체가 더 이상 사용되지 않으며 삭제할 수 있습니다. 마찬가지로 잔액이 수신자 객체에서 수신자 계정으로 이동한 후 수신자 객체를 삭제할 수 있습니다.

Public Ledger(상태 데이터베이스)	개인 데이터 수집
`operation_id` `token_name` `operation_type` `status` `assetType` `holding_id` `from_account_id` `from_org_id` `to_account_id` `notary_account_id` `token_id` `quantity`(암호화됨) `time_to_expiration` `sender_id` `category` `description`	`quantity` `blinding_factor` `assetType` `holding_id`

다음 테이블은 조직간 이전 및 보류에 대해 생성된 발신자 객체에 대한 정보를 보여 줍니다.

Public Ledger(상태 데이터베이스)	개인 데이터 수집
`assetType` `sender_id` `operation_id` `account_id` `transaction_id` `quantity`(암호화됨) `version`	`assetType` `sender_id` `blindingFactor`

다음 테이블은 조직간 이전 및 보류에 대해 생성된 수령인 객체에 대한 정보를 보여 줍니다.

Public Ledger(상태 데이터베이스)	개인 데이터 수집
`assetType` `receiver_id` `operation_id` `account_id` `transaction_id` `quantity`(암호화됨) `version`	`assetType` `receiver_id` `blindingFactor`

기밀 지급 사례에서 holdTokens 메소드는 token_id 및 선택적 매개변수를 입력으로 사용하며 수신자에 대한 userId 및 orgId 값 및 임시 맵에 전달된 토큰 수량과 함께 REST 프록시에서 전송되는 블라인딩 계수가 필요합니다.
공증 사용자가 보류 작업을 승인하거나 거부해야 합니다.
- 공증 사용자가 보류 작업을 승인하면 수량이 발신자 및 보류 객체에서 차변 기입되고 트랜잭션 객체가 생성됩니다. 수신자 객체도 생성되고 수량을 수신자 객체에 대변 기입합니다.
- 공증 사용자가 보류를 거부하면 보류 수량이 발신자의 계정에 다시 대변 기입되고 트랜잭션 객체가 생성됩니다.
잔액 약정, 실제 잔액 및 트랜잭션 객체가 공용 원장 및 개인 데이터 수집에 저장되어 모든 잔액을 그에 따라 업데이트합니다.

불타는 토큰

토큰을 레코딩하기 위해 버너 역할이 있는 사용자가 burnTokens API를 호출합니다.

기밀 지급 사례에서 burnTokens 메소드는 token_id 값을 입력으로 사용하고 임시 맵에 전달된 토큰 수량과 함께 REST 프록시에서 전송되는 블라인딩 계수가 필요합니다.
확인 후 Pedersen 약정은 블라인딩 계수 및 레코딩할 토큰 수량에서 생성됩니다.
그런 다음 전체 수량이 공용 원장과 개인 데이터 수집 모두에서 업데이트됩니다. 공공 원장에서 기존 잔액을 나타내는 페더슨 약정은 소모된 토큰 수량을 나타내는 페더슨 약정으로 감소합니다. 개인 데이터 수집에 저장된 잔액의 실제 값이 이에 따라 감소합니다.
블라인딩 계수도 업데이트되므로 언제든지 개인 데이터 수집의 잔액 및 블라인딩 계수를 사용하여 공공 원장에 저장된 해당 약정을 확인할 수 있습니다.