TLDR: Plasma Cash 변형에 대한 사양을 만들고 Node.js 및 Vyper에서 구현했습니다. 이 문서는 설계 사양을 다루며 그 과정에서 구현에 대한 참조를 제공합니다. 우리의 코드는 다른 플라즈마 체인과 해당 블록 탐색기의 온체인 레지스트리인 테스트넷에 새로운 체인을 배포하고 명령줄 지갑을 통한 거래를 지원합니다.

소개

확장성 솔루션으로서의 블록체인 네트워크에 대한 비전은 빠르게 확산되고 있습니다. 트랜잭션 병렬화를 위한 다중 체인 접근 방식은 처리량을 늘리는 유망한 방법입니다. 불행히도 다음과 같은 중요한 문제도 있습니다.

• 우리는 보안을 나누기를 원하지 않습니다. 예를 들어 각각 전체 보안의 1%인 100개의 체인입니다.

• 샤딩과 같은 고급 솔루션은 유망하지만 아직 준비되지 않았습니다.

다음과 같은 확장성 솔루션이 필요합니다.

• 수백만 달러의 채굴 수수료를 지불하지 않고 이더리움 메인넷과 유사한 수준의 보안을 제공합니다.

• 오늘날 존재하는 이더리움에서 구현할 수 있습니다.

우리는 이러한 기준을 충족하는 가장 강력한 후보는 Plasma 프레임워크를 통해 메인넷에 각각 보안되는 체인 네트워크라고 믿습니다.

Plasma는 개인이 높은 처리량의 안전한 블록체인을 쉽게 배포할 수 있도록 하는 프로토콜 제품군입니다. 이더리움 메인 체인의 스마트 계약은 "플라즈마 체인"이 완전히 악의적으로 작동하더라도 사용자의 자금을 안전하게 보호할 수 있습니다. 이렇게 하면 사이드 체인과 같은 신뢰할 수 있는 페깅 메커니즘이 필요하지 않습니다. 플라즈마 체인은 비수탁형이므로 보안을 희생하지 않고 확장성의 우선 순위를 지정할 수 있습니다.

우리는 사용자가 거래하는 곳을 선택할 수 있는 많은 플라즈마 체인이 있는 미래를 상상합니다. 따라서 플라즈마 체인 구현을 출시하면서 PlasmaRegistry.vy. 레지스트리는 새로운 체인이 IP/DNS 주소, 사용자 지정 "이름" 문자열 및 계약 주소를 나열하여 네트워크에 가입할 수 있도록 합니다. 레지스트리 계약은 신뢰할 수 있는 배포를 확인하므로 사용자는 해당 운영자가 악의적인 경우에도 해당 레지스트리의 모든 계약이 보관하기에 안전하다는 것을 확신할 수 있습니다 .

플라즈마 체인 구현의 속성

이 게시물은 연구 커뮤니티 내에서 최근 개발된 Plasma Group의 현재 프로토콜 및 구현을 지정합니다.

우리의 사양에는 다음과 같은 속성이 있습니다.

• Plasma Cash의 "고정 액면가" 문제를 해결하는 광범위한 코인에 대한 단일 거래 .

• 예금 수가 아닌 거래 수에 따라 확장되는 블록 크기.

• 라이트 클라이언트 증명은 입금 이후 블록 크기의 로그 및 선형으로 확장되어 운영자를 시스템의 유일한 (계산) 병목 현상으로 만듭니다.

• 종료가 트랜잭션과 그 부모 대신 가장 최근의 트랜잭션만 지정할 수 있도록 하는 단순화되고 낙관적인 종료 절차입니다 .

• 분산형 교환 프로토콜의 토대를 마련하는 인터체인 아토믹 스왑.

• 무제한 입금 용량.

구현은 위의 사양을 따르며 다음을 제공합니다.

• Javascript로 작성된 명령줄 플라즈마 체인 연산자 입니다.

• 명령줄 지갑과 함께 Javascript로 작성된 플라즈마 클라이언트 구현입니다 .

• Vyper로 작성된 ETH 및 ERC20 토큰을 지원하는 스마트 계약 .

• 클라이언트가 라이트 클라이언트 증명을 다운로드하고 확인하고 거래할 수 있는 통합 JSON RPC입니다 .

• 플라즈마 운영자가 호스팅하는 블록 탐색기 .

• 부하 테스트를 위해 트랜잭션을 생성하는 시뮬레이션된 클라이언트 스웜 .

• 사용자가 탐색할 수 있는 안전한 것으로 확인된 계약 및 운영자 IP 주소 집합을 나열하는 플라즈마 "레지스트리" 계약.

프로토콜과 코드 구현을 확인하는 데 관심이 있다면 잘 찾아오셨습니다!

그러나 파헤치기 전에 몇 가지 면책 사항이 있습니다.

• 우리의 플라즈마 구현은 현재 테스트넷 사용에만 적합한 베타 소프트웨어입니다. 현재 치명적인 버그가 분명히 있습니다.

• 이 프로토콜과 다른 Plasma 구현 간의 주요 차이점(아래에 설명!)은 블록 구조입니다.머클합집합나무. 이것은 상당한 이점이 있지만 복잡성을 추가합니다. 플라즈마는 사이드체인에 비해 이미 복잡합니다.

• 코드는 아직 감사 또는 공식적으로 검증되지 않았으며 최적화를 거치지 않았습니다.

• 연산자가 유일한 연산 병목 지점이지만 오늘날 주요 성능 제한은 여전히 ​​대역폭입니다. 양육권 증명에는 블록 수에 선형적인 다운로드가 필요합니다. 우리의 코드는 블록당 개선되었지만 여전히 선형입니다. 이 활발한 연구 영역은 아직 구현 준비가 되어 있지 않습니다.

• 우리의 안전 메커니즘과 종료 게임이 모두 구현되고 테스트되었지만 아직 자동화된 가드 서비스를 구축하지 않았으므로 문제와 대응을 수동으로 구성해야 합니다.

방해가되지 않도록 뛰어 들자! 이 게시물의 나머지 부분에서는 사양, 코드가 있는 위치 및 기능에 대해 포괄적으로 살펴보겠습니다.

목차

1. 일반 정의 및 데이터 구조 a. 코인 ID 할당 b. 교단

2. 코인 범위에 대한 거래 a. 이동 b. 유형이 지정된 경계와 유형이 지정되지 않은 경계 c. 다중 전송 및 전송/트랜잭션 원자성 d. 직렬화

3. 블록 구조 사양 a. 합계 트리 노드 사양 b. 부모 계산 c. 분기 범위 계산 d. 리프로 전송 구문 분석 e.

리포지토리 및 아키텍쳐

Github는 MIT 라이선스에 따라 모든 구현을 제공합니다.

• plasma-chain-operator: 나만의 플라즈마 체인을 가동하고 테스트넷에 배포합니다.

• plasma-core: 핵심 플라즈마 클라이언트 기능 - 논리의 이식 가능한 고기.

• plasma-node: plasma-coreCLI 구현을 위한 Node.js 래퍼

• plasma-js-lib: 플라즈마 트랜잭션을 통합하는 웹 애플리케이션 구축을 위한 JS 도우미입니다.

• plasma-contracts: The PlasmaChain.vy와 PlasmaRegistry.vyVyper의 계약.

• plasma-explorer: 운영자가 호스팅하는 블록탐색기.

• plasma-utils: 플라즈마 사양을 구축하기 위한 공유 유틸리티.

• plasma: 위 구성 요소에 대한 통합 테스트.

구현하는 아키텍처는 다음과 같습니다 plasma-core.

구현하는 아키텍처는 다음과 같습니다 plasma-chain-operator.

이 섹션에서는 프로토콜 구성 요소에 대한 용어와 직관을 다룹니다. plasma-utils이러한 데이터 구조는 '라이브러리' 에 의해 인코딩 및 디코딩됩니다 serialization. 각 구조에 대한 모든 데이터 구조의 정확한 바이트당 이진 표현은 스키마 에서 찾을 수 있습니다 .

코인ID 할당

플라즈마 자산의 기본 단위는 코인으로 표시됩니다. 표준 Plasma Cash와 마찬가지로 이 코인은 대체 불가능하며 코인의 인덱스를 coinID16바이트인 이라고 합니다. 자산(ERC 20/ETH) 기준으로 예치된 순서대로 할당됩니다. 특히 체인의 모든 자산은 ERC20 또는 ETH가 다르더라도 동일한 ID 공간을 공유합니다. tokenType즉, 모든 자산 클래스( 또는 라고 함 token)의 트랜잭션이 동일한 트리를 공유하여 최대 압축을 제공합니다.

처음 4바이트는 동전의 를 참조하고 tokenType다음 12바이트는 해당 특정 의 가능한 모든 동전을 나타내어 이를 달성합니다 tokenType.

예를 들어, 0번째 tokenType는 항상 ETH이므로 첫 번째 입금은 입금자에게 ETH코인에 대한 사용 권한을 부여합니다 .0x00000000000000000000000000000000

예금당 받는 총 코인은 정확히 (amount of token deposited)/(minimum token denomination)많습니다.

예를 들어, tokenType1이 이고 DAI, 동전 액면가가 이고 0.1 DAI, 첫 입금자가 을 보낸다고 가정해 봅시다 0.5 DAI. 즉 , 첫 번째 예금자는 최대 코인을 포함하여 s를 tokenType == 1받게 됩니다 .coinID0x000000010000000000000000000000000x00000001000000000000000000000004

실제로는 교단이 0.1. 액면가를 계약에 직접 저장하는 대신 예치된 금액 (또는 ETH의 경우)과 수신된 플라즈마 코인 수 사이의 소수점 자리 이동을 나타내는 decimalOffset각각의 매핑을 저장합니다. 이러한 계산은 스마트 계약 의 , 및 함수 에서 찾을 수 있습니다.tokenTypeERC20weidepositERC20depositETHfinalizeExit

//참고: decimalOfset이 릴리스에서는 s가 0으로 하드코딩됩니다. 클라이언트/운영자 코드에서 지원이 부족하기 때문입니다.

트랜스퍼

트랜잭션은 지정된 숫자와 트랜잭션의 각 범위에 대한 세부 정보를 설명하는 개체 block배열 로 구성됩니다. 스키마Transfer 에서 ( s 바이트):plasma-utilslength

https://gist.githubusercontent.com/ben-chain/2c3818f78846289a15be1aa175f35ca5/raw/04c7d06627c995b0641c792cf8fac9c12af16318/transfer.js

Transfera 의 각 항목 은 , , , 및 를 Transaction지정하는 것을 볼 수 있습니다 .tokenTypestartendsenderrecipient

형식화 및 형식화되지 않은 경계

start위에서 주목해야 할 한 가지는 및 end값이 s와 같은 16바이트가 아니라 12바이트라는 것입니다 coinID. 이는 예금에 대한 위 섹션의 맥락에서 이해되어야 합니다. coinID전송에 의해 설명된 실제 s를 얻기 위해 필드의 4바이트를 및 token왼쪽에 연결합니다 . 우리는 일반적으로 12바이트 버전을 's and' 라고 부르며 연결된 버전을 ' and' 라고 합니다 . 이러한 값은 serializer에서도 노출 됩니다 .startendtransferuntypedStartuntypedEndtypedStarttypedEnd

또 다른 참고 사항: 모든 전송에서 해당 s는 포함 및 배타적 coinID으로 정의됩니다 . 즉, 전송된 정확한 s는 입니다 . 예를 들어 처음 100개의 ETH 코인은 with , 및 와 함께 보낼 수 있습니다 . 두 번째 100은 및 .startendcoinID[typedStart, typedEnd)Transfertransfer.token = 0transfer.start = 0transfer.end = 100transfer.start = 100transfer.end = 200

스키마 Transaction는 4바이트 block숫자(트랜잭션은 특정 플라즈마 블록에 포함된 경우에만 유효함)와 객체 배열 로 구성됩니다 Transfer. 이것은 트랜잭션이 여러 전송을 설명할 수 있음을 의미하며, 이는 모두 원자적으로 실행되거나 전체 트랜잭션의 포함 및 유효성에 의존하지 않습니다. 이것은 이후 릴리스에서 분산 교환 및 조각 모음 의 기초를 형성할 것입니다 .

직렬화

위에 예시된 것처럼 plasma-utils데이터 구조에 대한 사용자 지정 직렬화 라이브러리를 구현합니다. JSON RPC와 스마트 계약은 모두 직렬 변환기에 의해 인코딩된 바이트 배열을 사용합니다.

인코딩은 매우 간단하며 스키마에 의해 정의된 바이트 수로 고정된 각 값을 연결합니다.

Transaction1개 이상의 s를 포함하는 객체 와 같이 가변 크기 배열을 포함하는 인코딩의 경우 Transfer단일 바이트가 요소 수 앞에 옵니다. 직렬화 라이브러리에 대한 테스트는 여기에서 찾을 수 있습니다 .

현재 다음 개체에 대한 스키마가 있습니다.

• Transfer

• UnsignedTransaction

• Signature

• SignedTransaction

• TransferProof

• TransactionProof

  3. 블록 구조 사양

  Plasma Cash가 도입한 가장 중요한 개선 사항 중 하나는 "라이트 프루프"였습니다. 이전에는 플라즈마 구성에서 사용자가 자금의 안전을 보장하기 위해 전체 플라즈마 체인을 다운로드해야 했습니다. Plasma Cash를 사용하면 자신의 자금과 관련된 Merkle 트리의 가지만 다운로드하면 됩니다.

  이것은 새로운 트랜잭션 유효성 조건을 도입하여 달성되었습니다 . 특정 트랜잭션은 Merkle 트리의 th 리프 coinID에서만 유효합니다 . 따라서 해당 코인에 대한 유효한coinID 트랜잭션이 존재 하지 않는다는 확신을 가지려면 해당 분기만 다운로드하는 것으로 충분합니다 . 이 방식의 문제는 트랜잭션이 이 액면가에 "고정"되어 있다는 것입니다. 여러 개의 코인을 트랜잭션하려면 각 리프에 하나씩 여러 트랜잭션이 필요합니다.

  안타깝게도 범위 기반 트랜잭션을 일반 Merkle 트리의 분기에 넣으면 라이트 증명이 안전하지 않게 됩니다. 하나의 분기가 있다고 해서 다른 분기가 교차하지 않는다는 보장이 없기 때문입니다.

일반 Merkle 트리에서 다른 분기가 교차하지 않도록 보장하는 유일한 방법은 모두 다운로드 하고 확인하는 것입니다. 그러나 그것은 더 이상 가벼운 증거가 아닙니다!

플라즈마 구현의 중심에는 새로운 블록 구조 와 수반되는 새로운 트랜잭션 유효성 조건이 있어 범위 기반 트랜잭션에 대한 가벼운 증명을 얻을 수 있습니다. 블록 구조는 머클 합계 트리라고 하며 각 해시 옆에는 sum값이 있습니다.

새 유효성 조건은 sum특정 분기의 값을 사용하여 aa start및 end범위를 계산합니다. 이 계산은 두 분기의 계산 범위가 겹치는 것이 불가능 하도록 특별히 제작되었습니다 . A는 transfer자신의 범위가 해당 범위 내에 있는 경우에만 유효하므로 라이트 클라이언트를 다시 얻을 수 있습니다!

이 섹션에서는 합계 트리의 정확한 사양, 실제로 범위 계산이 무엇인지, 범위 계산을 만족하는 트리를 실제로 구성하는 방법을 지정합니다. 이 사양으로 이끈 연구에 대한 자세한 배경과 동기는 이 게시물을 확인하세요.

우리는 플라즈마 머클 합계 트리의 두 가지 구현을 작성했습니다. 하나는 운영자를 위해 데이터베이스에서 수행되고 다른 하나 는 .plasma-utils

Merkle 합계 트리의 각 노드는 다음과 같이 48바이트입니다 [32 byte hash][16 byte sum] . sum의 16바이트 길이가 coinID!

이 두 부분을 끌어내는 두 개의 도우미 속성 .hash및 가 있습니다 . .sum예를 들어 일부의 경우 및 이 node = 0x1b2e79791f28c27ed669f257397e1deb3e522cf1f27024c161b619d276a25315ffffffffffffffffffffffffffffffff있습니다 . node.hash == 0x1b2e79791f28c27ed669f257397e1deb3e522cf1f27024c161b619d276a25315node.sum == 0xffffffffffffffffffffffffffffffff

일반 Merkle 트리에서 단일 루트 노드까지 해시 노드의 이진 트리를 구성합니다. 합계 트리 형식을 지정하는 것은 parent(left, right)두 형제를 인수로 받아들이는 계산 함수를 정의하는 간단한 문제입니다. 예를 들어 일반 Merkle 합계 트리에는 다음이 있습니다. 해시 함수는 parent = function (left, right) { return Sha3(left.concat(right)) } 어디에 있고 두 값을 함께 추가합니다.Sha3concat

Merkle 합계 트리를 생성하려면 parent함수는 자식 고유 .sum값에 대한 추가 작업의 결과도 연결해야 합니다.

부모 = 기능 (왼쪽, 오른쪽) { 
반환 Sha3(left.concat(right)).concat(left.sum + right.sum) 
}

예를 들어, 우리는

부모(0xabc…0001, 0xdef…0002) === 
해시(0xabc…0001.concat(0xdef…0002)).concat(0001 + 0002) === 
0x123…0003

는 해시뿐만 아니라 parent.hash각각에 대한 약속입니다 . 우리는 둘 다의 전체 96바이트를 해시합니다.sibling.sum

분기 범위 계산

머클 합계 트리를 사용하는 이유는 분기가 설명하는 특정 범위를 계산할 수 있고 다른 유효하고 겹치는 분기가 존재하지 않는다는 것을 100% 확신할 수 있기 때문입니다.

우리는 a를 더하고 가지를 위로 올라가서 leftSum이 범위를 계산합니다. rightSum각 상위 계산에서 둘 다 0으로 초기화하면 포함 증명이 오른쪽에 형제를 지정하면 를 취하고 rightSum += right.sum왼쪽에 있으면 를 추가합니다 leftSum += left.sum.

그런 다음 분기가 설명하는 범위는 [leftSum, root.sum — rightSum). 다음 예를 참조하십시오.

이 예에서 분기 6의 유효 범위는 입니다 [21+3, 36–5) == [24, 31). 31–24=7리프 6의 합계 값인 에 주목하십시오 ! 마찬가지로 분기 5의 유효 범위는 입니다 [21, 36-(7+5)) == [21, 24). 그 끝은 분기 6의 시작과 동일합니다!

가지고 놀아 보면 동일한 범위를 포함하는 두 개의 다른 가지로 Merkle sum 트리를 구성하는 것이 불가능하다는 것을 알 수 있습니다. 트리의 어떤 수준에서는 합계가 깨져야 합니다! 계속해서 범위(4.5,6)와 교차하는 다른 분기를 만들어 리프 5 또는 6을 "속이세요". 회색 상자에 s 만 입력 ?:

트리의 특정 수준에서는 항상 불가능하다는 것을 알 수 있습니다.

이것이 우리가 라이트 클라이언트를 얻는 방법입니다. 포함 증명에서 "암시적으로" 계산되기 때문에 분기 범위 범위를 implicitStart및 라고 부릅니다. 테스트 및 클라이언트 측 증명 확인을 위해 구현 implicitEnd된 분기 검사기가 있습니다 .plasma-utilscalculateRootAndBounds()

Vyper에서 스마트 계약을 통해

범위는 시작과 끝 으로 입력되며 전체 16바이트입니다.

일반 Merkle 트리에서 "잎"을 해싱하여 노드의 맨 아래 계층을 구성합니다.

우리의 경우 잎이 트랜잭션이 되기를 원합니다. 따라서 해싱은 간단하지만 여전히 .sum트리의 최하위 수준에 대한 값이 필요합니다.

txA단일 을 가진 일부가 주어지면 transferA합계 값은 무엇입니까? . _ _ transferA.end — transferA.start_ 그 이유는 전송이 닿지 않으면 가지의 범위를 망치기 때문입니다. 이 차이를 설명하기 위해 합계 값을 "채워야" 합니다. 그렇지 않으면 값이 root.sum너무 작아집니다.

흥미롭게도 이것은 간격의 오른쪽이나 왼쪽에 노드를 채울 수 있기 때문에 비결정적 선택입니다. 리프를 블록으로 구문 분석하기 위해 다음과 같은 "왼쪽 정렬" 방식을 선택했습니다.

.sum해당 분기 에 대한 최하위 값을 호출 parsedSum하고 스키마에는 최하위 노드를 재구성하는 데 사용되는 값이 TransferProof포함됩니다 ..parsedSum

따라서 스마트 컨트랙트에서 확인하는 브랜치의 유효 조건은 다음과 같습니다 implicitStart <= transfer.typedStart < transfer.typedEnd <= implicitEnd. "Plasma Cashflow" 합계 트리의 원래 디자인에서 일부 리프는 거래되지 않은 범위를 나타내기 위해 특수한 "NoTx" 트랜잭션으로 채워졌습니다. 이 형식을 사용하면 거래되지 않는 코인은 단순히 범위 [implicitStart, transfer.typedStart)및 [transfer.typedEnd, implicitEnd). 스마트 계약은 이 범위의 어떤 코인도 출구에 대한 도전이나 응답에 사용할 수 없도록 보장합니다.

종종 (거래 수수료 및 교환을 지원하기 위해) 거래는 유효하기 위해 원자적으로 발생하거나 발생하지 않는 다중 전송을 요구합니다. 그 효과 는 유효한 거래가 .transfers각각에 대해 한 번씩 포함되어야 한다는 것입니다 . 그러나 이러한 각 포함에 대해 여전히 맨 아래까지 파싱되는 것은 개인이 아닌 전체 의 해시입니다 .transfer.typedStart.typedEndUnsignedTransactionTransfer.hash

기존의 블록체인 시스템과 달리 전체 플라즈마 노드는 모든 단일 트랜잭션을 저장하지 않고 자신이 소유한 자산과 관련된 정보만 저장하면 됩니다. 이것은 보낸 사람이 실제로 주어진 범위를 소유하고 있음을 증명 해야sender 함 을 의미합니다. 완전한 증명에는 이더리움 체인 자체가 분기되지 않는 경우 메인 체인에서 토큰을 교환할 수 있음을 보장하기에 충분한 모든 정보가 포함되어 있습니다.recipient

증명은 주로 해당 코인에 대한 관리 체인을 업데이트하는 트랜잭션의 포함 및 비포함으로 구성됩니다. 포함 루트는 운영자가 메인 체인의 스마트 계약에 제출한 블록 해시와 비교하여 확인해야 합니다. 토큰의 최초 예치금부터 계약에 이르기까지 증명 체계에서 검증된 대로 관리 사슬을 추적함으로써 상환 능력이 보장됩니다.

plasma-core들어오는 트랜잭션 증명을 확인하기 위한 비교적 간단한 방법론을 따릅니다. 이 섹션에서는 해당 방법론에 대해 설명합니다.

역사 증명은 일련의 예금 기록 과 Transaction해당 s가 있는 관련 s 의 긴 목록으로 구성됩니다 TransctionProof.

plasma-utils 에 대한 호출을 통해 여기static checkTransactionProof(transaction, transactionProof, root) 에서 사용되는 메서드를 노출 합니다 .plasma-core ProofService

개체 TransactionProof에는 주어진 의 유효성을 확인하는 데 필요한 모든 정보가 포함되어 있습니다 Transaction. 즉, 단순히 객체 의 배열 입니다 TransferProof. Atomic multisends에 대한 위의 섹션에 따라 주어진 TransactionProof모든 것이 유효한 경우에만 유효합니다 TransferProofs.

TransferProofs올바른 블록 번호 Transfer에서 제공된 에 해당하는 유효한 분기 포함을 복구하는 데 필요한 모든 필수 정보를 포함합니다 . Transaction이는 다음을 구성합니다.

• 분기의 전체 'inclusionProof'를 나타내는 Merkle 합계 트리의 실제 노드

• 분기가 추적하는 이진 경로를 계산하기 위한 잎의 인덱스

• .sum위의 합계 트리 사양에 설명된 대로 구문 분석된 하단

• signature특정 발신자에 대한 입니다 .

plasma-utils 스키마 에서 바로 :

는 inclusionProof크기가 트리의 깊이에 따라 달라지는 가변 길이 배열입니다.

검증 프로세스의 핵심은 입금부터 시작하여 각 증명 요소를 현재 "검증된" 상태에 적용하는 것입니다. 증명 요소가 유효한 상태 전환을 초래하지 않으면 증명을 거부해야 합니다.

각 증명 요소를 적용하는 프로세스는 직관적입니다. 계약의 보관 규칙에 따라 각 블록에 트랜잭션을 적용하기만 하면 됩니다.

역사적으로 소유된 범위를 추적하는 방법을 snapshot. 간단히 말해서 블록에서 확인된 범위 소유자를 나타냅니다.

수신된 모든 범위는 해당 보증금에서 가져와야 합니다. 예금 레코드는 token, start, end, depositer및 로 구성됩니다 blockNumber.

각 입금 기록에 대해 검증자는 청구된 입금이 실제로 발생했는지 확인하고 그 동안 어떠한 종료도 발생하지 않았는지 확인하기 위해 이더리움을 다시 확인해야 합니다 .

그렇다면 배열은 각각 이 예금자인 verifiedSnapshots이러한 예금으로 초기화됩니다 .snapshot.owner

TransactionProof다음으로 주어진 s를 모두 적용하고 verifiedSnapshots그에 따라 업데이트합니다. 각 transaction해당 에 대해 transactionProof검증자는 다음 단계를 수행합니다.

1. 주어진 증명 요소가 유효한지 확인하십시오. 그렇지 않은 경우 오류를 발생시킵니다.

2. transfer의 각각에 대해 transaction다음을 수행합니다 . transfer.typedStart, transfer.typedEnd, implicitStart및 implicitEnd b 에서 위에서 업데이트된 모든 스냅샷을 "분할"합니다 . c 와 같은 모든 .block결과에 대해 숫자를 증가시킵니다 . 와 사이에 있는 각 분할에 대해 : i. 확인하십시오 . 그렇지 않은 경우 오류를 발생시킵니다. ii. 설정합니다 .verifiedSnapshotsblocktransaction.blockNumber — 1 snapshottransfer.starttransfer.end snapshot.owner === transfer.from snapshot.owner = transfer.sender

는 TransactionProofs오름차순으로 적용해야 합니다 blockNumber.

이 작업이 모든 에 대해 재귀적으로 적용되면 TransactionProof클라이언트는 현재 플라즈마 블록 verifiedSnapshots과 blockNumber동일한 모든 요소와 owner주소가 동일한 모든 요소를 ​​검색하여 현재 소유하고 있는 새로운 코인을 확인할 수 있습니다.

위 1단계의 트랜잭션 유효성 검사는 스마트 계약의 유효성 조건을 검사하는 것과 같습니다. 위의 합계 트리 사양을 기반으로 한 기본 유효성 검사는 다음과 같습니다.

1. 트랜잭션 인코딩이 올바른 형식인지 확인합니다.

2. 각 transfer해당 항목 에 대해 transferProof: a. 가 해당 주소 signature로 확인되는지 확인합니다 . b. c에 의해 정의된 이진 경로를 사용하여 해당 플라즈마 블록에 대한 루트 해시와 동일한 루트가 있는지 확인합니다 . 분기의 and를 계산 하고 다음을 확인합니다.transfer.sender inclusionProofleafIndex implicitStartimplicitEndimplicitStart <= transfer.start < transfer.end <= implicitEnd

   4.계약 및 종료 게임

   물론 자금을 안전하게 유지하기 위해 메인 체인으로 전달될 수 없다면 관리 사슬에 대한 증거는 유용하지 않습니다. 온체인에서 증명을 받아들이는 메커니즘은 플라즈마의 보안 모델의 핵심이며, 이를 "엑시트 게임"이라고 합니다.

   사용자가 플라즈마 체인에서 돈을 옮기고 싶을 때 분쟁 기간을 여는 "출구"를 만듭니다. 분쟁 기간이 끝날 때 미해결 분쟁이 없으면 메인 체인의 플라즈마 계약에서 종료자에게 돈이 전송됩니다. 분쟁 기간 동안 사용자는 퇴출되는 돈이 퇴장하는 사람의 정당한 소유가 아니라고 주장하는 "도전"을 제출할 수 있습니다. 위에서 설명한 증명은 이러한 문제에 대한 "응답"이 항상 계산 가능함을 보장합니다.

   출구 게임의 목표는 최대한 적대적인 운영자의 경우에도 돈을 안전하게 유지하는 것입니다. 특히 완화해야 하는 세 가지 주요 공격이 있습니다.

   • 데이터 보류: 운영자는 계약에 루트 해시를 게시할 수 있지만 블록의 내용이 무엇인지 누구에게도 알리지 않습니다.

   • 위조/무효 트랜잭션 포함sender : 운영자는 이전 recipient에 Chain of Custody 가 아닌 블록에 트랜잭션을 포함할 수 있습니다 .

   • 검열: 누군가가 돈을 입금한 후 운영자는 돈을 보내는 모든 거래를 게시하는 것을 거부할 수 있습니다.

   이 모든 경우에 종료 게임의 챌린지/응답 프로토콜은 최대 1개의 챌린지와 1개의 응답에서 이러한 동작이 절도를 허용하지 않도록 합니다.

입금 매핑

다시, 우리는 범위의 시작에 액세스하기 위해 호출할 수 있도록 키 tokenType와 함께 이중 중첩 매핑을 사용합니다 . Vyper는 설정되지 않은 모든 매핑 키에 대해 0을 반환하므로 사용자가 설정되지 않은 을 전달하여 계약을 "속일" 수 없도록 bool이 필요합니다 .untypedEndself.exitable[tokenType][untpyedEnd].untypedStartisSetexitableRange

계약의 범위는 이라는 도우미 함수를 통한 self.exitable성공적인 호출에 따라 분할 및 삭제됩니다 . 이전에 종료된 범위의 종료는 챌린지할 필요조차 없습니다. 그들은 결코 시험을 통과하지 못할 것입니다 . 여기에서 해당 코드를 찾을 수 있습니다 .finalizeExitremoveFromExitablecheckRangeExitablefinalizeExit

Exit 게임과 바닐라 플라즈마 캐시의 관계 본질적으로 우리 사양의 종료 게임은 원래 Plasma Cash 디자인과 매우 유사합니다. 종료는 함수 호출로 시작됩니다.

beginExit(tokenType: uint256, blockNumber: uint256, untypedStart: uint256, untypedEnd: uint256) -> uint256: 종료에 대해 이의를 제기하기 위해 모든 챌린지는 특정 coinID질문을 지정하고 플라즈마 캐시 스타일 챌린지 게임은 특정 코인에 대해 수행됩니다. 전체 퇴장을 취소하려면 단 하나의 코인만 유효하지 않은 것으로 입증되어야 합니다.

출구와 응답 가능한 두 가지 유형의 도전에는 exitID및 challengeID증가를 통해 순서대로 할당되는 및 가 challengeNonce지정 됩니다 exitNonce.

블록번호 지정 트랜잭션 원래 Plasma Cash 사양에서 종료자는 운영자가 유효한 트랜잭션 포함을 지연하고 유효하지 않은 트랜잭션을 블록 사이에 삽입하는 "인플라이트" 공격을 방지하기 위해 종료된 트랜잭션과 이전 "상위" 트랜잭션을 모두 지정해야 합니다. .

트랜잭션에 여러 부모가 있을 수 있기 때문에 범위 기반 체계에 문제가 있습니다. 예를 들어 Alice가 Carol에게 보내고 Bob이 Carol에게 (0, 50]보낸다면 Carol은 이제 Dave에게 보낼 수 있습니다. 그러나 Dave가 종료하려는 경우 및 둘 다 부모 입니다.(50, 100](0, 100](0, 50](50, 100]

여러 부모를 지정하는 것은 확실히 가능하지만 이 사양은 비용이 많이 들고 구현하기가 더 복잡해 보였습니다. 그래서 우리는 더 간단한 대안을 선택했습니다. 각 트랜잭션은 발신자가 의도한 '블록'을 지정하고 다른 블록에 포함된 경우 무효화됩니다. 이것은 기내 공격을 해결하고 계약에 트랜잭션의 부모가 필요하지 않음을 의미합니다. 이 체계에 대한 공식적인 문서 작성 및 안전 증명에 관심이 있는 사람들은 이 훌륭한 게시물을 살펴볼 가치가 있습니다 .

코인별 거래 유효성 먼저 주목할 가치가 있는 출구 게임의 직관적이지 않은 속성은 특정 트랜잭션이 해당 범위의 일부 코인에 대해 "유효"할 수 있지만 다른 코인에 대해서는 유효하지 않을 수 있다는 것입니다.

예를 들어 Alice가 (0, 100]Bob에게 전송하고 Bob이 (50, 100]Carol에게 전송한다고 가정합니다. Carol은 Alice가 전체 의 정당한 소유자인지 확인할 필요가 없습니다(0, 100] . Carol은 Alice가 소유한 보증 (50, 100], 즉 그녀의 영수증에 적용되는 보관 체인의 일부만 필요로 합니다. Alice가 를 소유하지 않은 경우 트랜잭션이 어떤 의미에서 "무효"일 수 있지만 (0, 50]스마트 계약은 코인에 대한 출구와 관련된 분쟁의 목적으로 이를 신경 쓰지 않습니다(50, 100] . 받은 코인의 소유권이 확인되는 한 나머지 거래는 중요하지 않습니다.

이것은 라이트 클라이언트 증명의 크기를 유지하기 위한 매우 중요한 요구 사항입니다. Carol이 full 을 확인해야 하는 경우 의 겹치는 상위 항목을 확인 하고 모든 상위 항목을 (0, 100]확인해야 할 수도 있습니다 . (0, 10000]이 "계단식" 효과는 트랜잭션이 매우 상호 의존적인 경우 증명의 크기를 엄청나게 증가시킬 수 있습니다.

이 속성은 교환되는 여러 범위를 설명하는 원자적 다중 전송에도 적용됩니다. Alice가 1 ETH를 Bob의 1 DAI와 거래하는 경우 서명하기 전에 Bob이 1 Dai를 소유하고 있는지 확인하는 것은 Alice의 책임입니다. 그러나 이후 Bob이 1 ETH를 Carol에게 보낸다면 Carol은 Bob이 1 DAI를 소유했는지 확인할 필요 없이 Alice가 Bob에게 보낸 1 ETH를 소유했다는 사실만 확인할 필요가 있습니다. Alice가 위험을 감수했으므로 Carol은 그럴 필요가 없습니다.

스마트 계약의 관점에서 볼 때 이 속성은 coinID출구 내 특정 항목에 대해 항상 제출되는 문제의 직접적인 결과입니다.

계약에서 트랜잭션 확인을 처리하는 방법 종료 게임에서 사용하려면 s 가 위의 증명 섹션(유효한 서명, 분기 경계 등)에 설명된 검사를 Transaction통과해야 합니다 . TransactionProof이 검사는 함수의 계약 수준에서 수행됩니다.

여기서 중요한 사항은 transferIndex논증입니다. 트랜잭션에는 여러 전송이 포함될 수 있으며 각 전송에 대해 트리에 한 번씩 포함되어야 합니다. 그러나 챌린지는 특정 을 참조하므로 coinID단일 전송만 관련됩니다. 따라서 챌린저와 리스폰더는 transferIndex이의를 제기하는 코인과 관련된 전송을 제공합니다. 검사는 TransferProof의 모든 s를 디코딩하고 검사 TransactionProof한 다음 함수를 사용하여 각각에 대한 포함을 검사합니다.

def checkTransferProofAndGetTypedBounds( leafHash: bytes32, blockNum: uint256, transferProof: bytes[1749] ) -> (uint256, uint256): # typedimplicitstart, typedimplicitEnd 모든 s가 확인되면 th TransferProof에 대한 분쟁 관련 값이 게임 종료 기능, 즉 , , , 및 로 반환됩니다 .transferIndexTransfersenderrecipienttypedStarttypedEndplasmaBlockNumber

이를 통해 종료를 위한 전체 챌린지/응답 게임 세트를 지정할 수 있습니다.

종료를 즉시 취소하는 챌린지 두 종류의 챌린지는 퇴장을 즉시 취소합니다: 사용된 코인에 대한 도전과 예치금이 발생하기 전에 퇴장한 도전.

소비된 코인 챌린지 이 챌린지는 트랜잭션 종료자가 이미 다른 사람에게 코인을 보냈음을 증명하는 데 사용됩니다.

@public def challengeSpentCoin( exitID: uint256, coinID: uint256, transferIndex: int128, transactionEncoding: bytes[277], transactionProofEncoding: bytes[1749], ): 다음을 사용 checkTransactionProofAndGetTypedTransfer하고 확인합니다.

챌린지된 coinID는 지정된 출구 내에 있습니다. 챌린지된 coinID는 의 th 요소 typedStart및 에 있습니다 .typedEndtransferIndextransaction.transfers plasmaBlockNumber출구보다 도전이 더 크다 . transfer.sender출구입니다 . 아토믹 스왑의 도입은 한 가지를 의미합니다. 운영자가 둘 이상의 당사자 간에 아토믹 스왑을 보류하는 극단적인 경우 때문에 사용된 코인 챌린지 기간은 다른 것보다 엄격하게 짧아야 합니다. 이 경우 해당 당사자는 사전 스왑된 코인을 종료해야 하며 운영자는 사용된 코인 챌린지를 수행하고 스왑이 포함되었는지 여부를 밝혀야 합니다. 그러나 운영자가 마지막 순간에 그렇게 하도록 허용하면 당사자가 공개를 사용하여 다른 종료를 취소할 시간이 없는 경합 상태가 됩니다. 따라서 시간 초과는 일반 챌린지 창보다 짧아(1/2) "마지막 순간 응답" 공격을 제거합니다.

입금 챌린지 이전 이 챌린지는 해당 코인이 실제로 입금된 것보다 일찍 출구가 발생했음을 입증하는 데 사용됩니다 .plasmaBlockNumber

@public def challengeBeforeDeposit( exitID: uint256, coinID: uint256, depositUntypedEnd: uint256 ): self.deposits[self.exits[exitID].tokenType][depositUntypedEnd].precedingPlasmaBlockNumber컨트랙트는 엑시트의 블록 번호보다 이후인지 조회 하고 확인합니다. 그렇다면 취소됩니다.

낙관적 출구 및 포함 문제 우리의 계약은 낙관적인 경우에 포함 확인을 전혀 수행하지 않고 종료가 발생하도록 허용합니다. 이를 허용하기 위해 모든 출구는 다음을 통해 직접 도전할 수 있습니다.

@public def ChallengeInclusion(exitID: uint256): 퇴출자는 퇴출하려는 거래 또는 입금으로 직접 응답해야 합니다.

@public def respondTransactionInclusion( ChallengeID: uint256, transferIndex: int128, transactionEncoding: 바이트[277], transactionProofEncoding: 바이트[1749], ): ... @public def respondDepositInclusion( ChallengeID: uint256, depositEnd: uint256 ): 두 번째 경우는 운영자가 입금 후 모든 거래를 검열한 경우 사용자가 돈을 인출할 수 있습니다.

다음과 같은 경우 두 응답 모두 챌린지를 취소합니다.

입금 또는 거래는 실제로 출구의 플라즈마 블록 번호에 있었습니다. 예금자 또는 수령인은 실제로 출구입니다. 출금의 시작과 끝이 입금이나 이체의 시작과 끝 안에 있었다 잘못된 역사 챌린지 바닐라 플라즈마 캐시와 이 사양 모두에 대해 가장 복잡한 도전-응답 게임은 역사 무효의 경우입니다. 프로토콜의 이 부분은 발신자가 이전 수신자가 아닌 위조된 "잘못된" 트랜잭션을 운영자가 포함하는 공격을 완화합니다. 그 해결책을 유효하지 않은 기록 챌린지라고 합니다. 정당한 소유자가 아직 코인을 사용하지 않았기 때문에 그들은 이를 증명하고 다음과 같이 도전합니다. 글쎄, 그것은 이전에 내 것이었고 내가 그것을 사용한 적이 있다는 것을 증명할 수 없습니다.”

유효하지 않은 기록 챌린지 및 응답은 모두 입금 또는 거래일 수 있습니다.

도전적인

현재 정당한 소유자에 따라 두 가지 방법으로 이의를 제기할 수 있습니다.

@public def challengeInvalidHistoryWithTransaction( exitID: uint256, coinID: uint256, transferIndex: int128, transactionEncoding: bytes[277], transactionProofEncoding: bytes[1749] ): 그리고

@public def challengeInvalidHistoryWithDeposit( exitID: uint256, coinID: uint256, depositUntypedEnd: uint256 ): 이 둘은

@private def challengeInvalidHistory( exitID: uint256, coinID: uint256, claimant: address, typedStart: uint256, typedEnd: uint256, blockNumber: uint256 ): coinID이 시도된 종료 내에 있고 이 blockNumber종료보다 이전인지 확인하는 작업을 수행하는 기능입니다 .

유효하지 않은 기록 문제에 대응

물론 유효하지 않은 히스토리 챌린지는 실제로 챌린저가 코인을 사용하고 관리 체인이 실제로 유효한 경우 슬픔일 수 있습니다. 우리는 이 응답을 허용해야 합니다. 두 종류가 있습니다.

첫 번째는 도전자의 지출을 보여주는 트랜잭션으로 응답하는 것입니다.

@public def respondInvalidHistoryTransaction( ChallengeID: uint256, transferIndex: int128, transactionEncoding: 바이트[277], transactionProofEncoding: 바이트[1749], ): 그런 다음 스마트 계약은 다음 확인을 수행합니다.

의 제 transferIndex는 도전 을 다룹니다 .TransfertransactionEncodingcoinID transferIndexth는 실제로 transfer.sender그 잘못된 역사 도전에 대한 청구인이었습니다. 트랜잭션의 플라즈마 블록 번호는 유효하지 않은 기록 챌린지와 종료 사이에 있습니다. 다른 응답은 코인이 실제로 예치되기 전에 챌린지가 왔다는 것을 보여주는 것입니다. 즉, 챌린지를 무효화하는 것입니다. 이는 challengeBeforeDepositfor 종료 자체와 유사합니다.

@public def respondInvalidHistoryDeposit( ChallengeID: uint256, depositUntypedEnd: uint256 ): 이 경우 챌린지가 유효하지 않기 때문에 보낸 사람이 챌린지 수신자인지 확인하지 않습니다. 따라서 계약은 다음을 확인해야 합니다.

보증금은 도전을 다룹니다 coinID. 보증금의 플라즈마 블록 번호는 도전과 출구 사이에 있습니다. 그렇다면 종료가 취소됩니다.

이것으로 완전한 종료 게임 사양을 마칩니다. 이러한 빌딩 블록을 사용하면 최대한 악의적인 플라즈마 체인의 경우에도 자금을 안전하게 유지할 수 있습니다.

구현에서 누락된 부분 Automated Guarding 시작은 좋았지만 이 사양과 그 이상에서 Plasma의 진정한 잠재력을 실현하려면 많은 개선이 필요합니다. 현재 구현에서 가장 눈에 띄게 누락된 부분은 사용자를 대신하여 챌린지 및 응답을 제출하는 자동화된 프로세스인 보호입니다. 고맙게도 출구 게임 자체가 구현되고 수동으로 테스트 되었으므로 체인이 배포된 후 클라이언트 소프트웨어를 업데이트할 수 있습니다. 우리는 이것이 테스트넷 릴리스에 충분하다고 느꼈지만 코드에 필요한 가장 시급한 추가 사항입니다.

P2P 이력 증명

현재 사용자가 거래를 받으면 운영자에게 요청하고 전체 증명을 다시 다운로드합니다. 이로 인해 운영자 오버헤드가 크게 증가합니다. 실제로 발생해야 하는 것은 발신자가 로컬에 저장된 증거를 수신자에게 직접 전송하여 운영자를 우회하고 플라즈마 체인을 실행하는 데 훨씬 저렴하게 만드는 것입니다.

조각 모음 전략 원자 스왑을 지원하므로 현재 사양은 계약을 업그레이드하지 않고도 모든 조각 모음 전략과 호환됩니다. 그러나 특히 플라즈마 블록 번호를 지정하기 위해 트랜잭션이 필요하기 때문에 올바른 접근 방식이 무엇인지는 여전히 남아 있습니다. 우리는 플라즈마 커뮤니티가 운영자와 사용자가 다양한 접근 방식을 시도할 수 있는 확장 가능한 조각 모음 추상화 라이브러리를 구축할 수 있기를 바랍니다.

프런트엔드 지갑 통합 프런트엔드 지갑에 대한 몇 가지 디자인이 있지만 현재 클라이언트는 다른 ERC20 거래를 지원하지 않고 명령줄 거래만 지원합니다. 테스트넷 사용자에게 멋진 UI를 제공하는 것은 UX 및 접근성 측면에서 중요한 단계가 될 것입니다.

운영자 수수료 Atomic multisend를 지원하기 때문에 프로토콜 수정 없이 거래 수수료를 지원할 수 있습니다. 그러나 현재 이 테스트넷 출시를 위해 구현된 것은 없습니다.

네트워크 운영자 우리가 아직 활용하지 못하고 있는 것은 머클 트리 구성이 고도로 병렬화 가능하다는 것입니다. 운영자가 네트워크 클러스터로 배포된 경우 하위 트리를 병렬로 구성하여 블록 크기를 늘릴 수 있습니다.

코드 검토 현재 모든 클라이언트, 계약 및 운영자 구현에 치명적인 버그가 있을 가능성 이 매우 높습니다 . 이 공개 출시의 일부가 외부 기여자가 많은 실수를 지적하는 데 도움이 되는 기회가 되기를 바랍니다!

사양의 누락된 부분 Succinct Proof Schemes 서론에서 언급했듯이 플라즈마 연구에서 가장 활발한 분야는 이력 증명 크기를 줄이기 위한 계획입니다. P2P 여부와 관계없이 오래된(예: 1년 이상) 코인에는 상당한 양의 관련 증명 데이터가 있어 거래가 번거로울 수 있습니다. 이력 증명에는 최소한 블록당 하나의 분기가 포함되어 있기 때문입니다.

RSA 누산기 구성과 여러 블록에 걸쳐 분기 증명을 배치하는 STARKS/SNARKS가 현재 가장 유력한 후보입니다. 둘 다 프로토콜 변경이 필요합니다. RSA(신뢰할 수 있는 설정도 도입)의 경우 완전히 새로운 유효성 조건을 종료 게임에 추가해야 합니다. 후자의 경우 EVM에서 구현되지 않은 SNARK/STARK 친화적 해싱 알고리즘을 사용하여 트리를 구성해야 합니다.

대량 퇴출/입금 체계 운영자가 악의적으로 변하면 사용자는 (결국 서두를 필요 없이!) 자금을 퇴출해야 합니다. 단일 온체인 트랜잭션을 통해 많은 사용자가 함께 탈퇴하는 데 동의하는 "대량 탈퇴"의 개념은 상당한 확장성 증가가 될 것입니다. 이상적으로, 출구는 잔고의 머클 루트를 통해 자금을 다른 플라즈마 체인에 직접 자동 예치할 수 있습니다. 이를 통해 많은 사용자가 메인 체인에서 개별 잔액을 해결하지 않고도 체인을 전환할 수 있습니다. 이는 여러 플라즈마 체인의 "네트워크 가능성"을 크게 향상시킵니다.

다중 운영자 네트워크 운영자는 자금을 훔칠 수 없지만 마음대로 거래를 검열할 수 있습니다. 이에 대한 한 가지 완화 방법은 단일 운영자 모델을 일련의 운영자로 대체하여 정직한 운영자 한 명만으로도 고객이 거래할 수 있도록 하는 것입니다.

종료 기록 개선 종료 가능한 범위 구성을 통해 종료된 범위에 대한 일정한 크기의 검사가 가능합니다. 그러나 각 종료가 이 매핑을 업데이트하므로 동일한 범위의 종료가 오름차순으로 처리되지 않으면 경쟁 조건이 발생합니다. 이는 첫 번째 종료의 종료가 범위를 분할하여 매핑에 대한 키를 변경 self.exitable하고 checkRangeExitable분할되지 않은 범위를 참조하는 종료가 실패하도록 하기 때문입니다. 이러한 종료는 되돌아가고 다음 이더리움 블록에서 다시 제출해야 합니다. 어떤 종류의 트리, 대기열 또는 일부 방법을 사용하는 가스 효율적인 대안이 존재할 수 있습니다 batchFinalizeExits.

상태 채널 및 스크립팅 최근 연구 커뮤니티에서 상태 채널 및 언약이 포함된 스크립팅이 Plasma에서 가능하다고 제안하는 몇 가지 큰 진전이 있었습니다. 현재 사양은 이러한 기능을 지원하지 않으며 지원하려면 스마트 계약을 크게 업그레이드해야 합니다.

함께, 우리는 보다 분산된 미래의 비전을 실현하기 위해 구축할 것입니다.

TLDR: Plasma Cash 변형에 대한 사양을 만들고 Node.js 및 Vyper에서 구현했습니다. 이 문서는 설계 사양을 다루며 그 과정에서 구현에 대한 참조를 제공합니다. 우리의 코드는 다른 플라즈마 체인과 해당 블록 탐색기의 온체인 레지스트리인 테스트넷에 새로운 체인을 배포하고 명령줄 지갑을 통한 거래를 지원합니다.

소개

확장성 솔루션으로서의 블록체인 네트워크에 대한 비전은 빠르게 확산되고 있습니다. 트랜잭션 병렬화를 위한 다중 체인 접근 방식은 처리량을 늘리는 유망한 방법입니다. 불행히도 다음과 같은 중요한 문제도 있습니다.

• 우리는 보안을 나누기를 원하지 않습니다. 예를 들어 각각 전체 보안의 1%인 100개의 체인입니다.

• 샤딩과 같은 고급 솔루션은 유망하지만 아직 준비되지 않았습니다.

다음과 같은 확장성 솔루션이 필요합니다.

• 수백만 달러의 채굴 수수료를 지불하지 않고 이더리움 메인넷과 유사한 수준의 보안을 제공합니다.

• 오늘날 존재하는 이더리움에서 구현할 수 있습니다.

우리는 이러한 기준을 충족하는 가장 강력한 후보는 Plasma 프레임워크를 통해 메인넷에 각각 보안되는 체인 네트워크라고 믿습니다.

Plasma는 개인이 높은 처리량의 안전한 블록체인을 쉽게 배포할 수 있도록 하는 프로토콜 제품군입니다. 이더리움 메인 체인의 스마트 계약은 "플라즈마 체인"이 완전히 악의적으로 작동하더라도 사용자의 자금을 안전하게 보호할 수 있습니다. 이렇게 하면 사이드 체인과 같은 신뢰할 수 있는 페깅 메커니즘이 필요하지 않습니다. 플라즈마 체인은 비수탁형이므로 보안을 희생하지 않고 확장성의 우선 순위를 지정할 수 있습니다.

우리는 사용자가 거래하는 곳을 선택할 수 있는 많은 플라즈마 체인이 있는 미래를 상상합니다. 따라서 플라즈마 체인 구현을 출시하면서 PlasmaRegistry.vy. 레지스트리는 새로운 체인이 IP/DNS 주소, 사용자 지정 "이름" 문자열 및 계약 주소를 나열하여 네트워크에 가입할 수 있도록 합니다. 레지스트리 계약은 신뢰할 수 있는 배포를 확인하므로 사용자는 해당 운영자가 악의적인 경우에도 해당 레지스트리의 모든 계약이 보관하기에 안전하다는 것을 확신할 수 있습니다 .

플라즈마 체인 구현의 속성

이 게시물은 연구 커뮤니티 내에서 최근 개발된 Plasma Group의 현재 프로토콜 및 구현을 지정합니다.

우리의 사양에는 다음과 같은 속성이 있습니다.

• Plasma Cash의 "고정 액면가" 문제를 해결하는 광범위한 코인에 대한 단일 거래 .

• 예금 수가 아닌 거래 수에 따라 확장되는 블록 크기.

• 라이트 클라이언트 증명은 입금 이후 블록 크기의 로그 및 선형으로 확장되어 운영자를 시스템의 유일한 (계산) 병목 현상으로 만듭니다.

• 종료가 트랜잭션과 그 부모 대신 가장 최근의 트랜잭션만 지정할 수 있도록 하는 단순화되고 낙관적인 종료 절차입니다 .

• 분산형 교환 프로토콜의 토대를 마련하는 인터체인 아토믹 스왑.

• 무제한 입금 용량.

구현은 위의 사양을 따르며 다음을 제공합니다.

• Javascript로 작성된 명령줄 플라즈마 체인 연산자 입니다.

• 명령줄 지갑과 함께 Javascript로 작성된 플라즈마 클라이언트 구현입니다 .

• Vyper로 작성된 ETH 및 ERC20 토큰을 지원하는 스마트 계약 .

• 클라이언트가 라이트 클라이언트 증명을 다운로드하고 확인하고 거래할 수 있는 통합 JSON RPC입니다 .

• 플라즈마 운영자가 호스팅하는 블록 탐색기 .

• 부하 테스트를 위해 트랜잭션을 생성하는 시뮬레이션된 클라이언트 스웜 .

• 사용자가 탐색할 수 있는 안전한 것으로 확인된 계약 및 운영자 IP 주소 집합을 나열하는 플라즈마 "레지스트리" 계약.

프로토콜과 코드 구현을 확인하는 데 관심이 있다면 잘 찾아오셨습니다!

그러나 파헤치기 전에 몇 가지 면책 사항이 있습니다.

• 우리의 플라즈마 구현은 현재 테스트넷 사용에만 적합한 베타 소프트웨어입니다. 현재 치명적인 버그가 분명히 있습니다.

• 이 프로토콜과 다른 Plasma 구현 간의 주요 차이점(아래에 설명!)은 블록 구조입니다.머클합집합나무. 이것은 상당한 이점이 있지만 복잡성을 추가합니다. 플라즈마는 사이드체인에 비해 이미 복잡합니다.

• 코드는 아직 감사 또는 공식적으로 검증되지 않았으며 최적화를 거치지 않았습니다.

• 연산자가 유일한 연산 병목 지점이지만 오늘날 주요 성능 제한은 여전히 ​​대역폭입니다. 양육권 증명에는 블록 수에 선형적인 다운로드가 필요합니다. 우리의 코드는 블록당 개선되었지만 여전히 선형입니다. 이 활발한 연구 영역은 아직 구현 준비가 되어 있지 않습니다.

• 우리의 안전 메커니즘과 종료 게임이 모두 구현되고 테스트되었지만 아직 자동화된 가드 서비스를 구축하지 않았으므로 문제와 대응을 수동으로 구성해야 합니다.

방해가되지 않도록 뛰어 들자! 이 게시물의 나머지 부분에서는 사양, 코드가 있는 위치 및 기능에 대해 포괄적으로 살펴보겠습니다.

목차

1. 일반 정의 및 데이터 구조 a. 코인 ID 할당 b. 교단

2. 코인 범위에 대한 거래 a. 이동 b. 유형이 지정된 경계와 유형이 지정되지 않은 경계 c. 다중 전송 및 전송/트랜잭션 원자성 d. 직렬화

3. 블록 구조 사양 a. 합계 트리 노드 사양 b. 부모 계산 c. 분기 범위 계산 d. 리프로 전송 구문 분석 e.

리포지토리 및 아키텍쳐

Github는 MIT 라이선스에 따라 모든 구현을 제공합니다.

• plasma-chain-operator: 나만의 플라즈마 체인을 가동하고 테스트넷에 배포합니다.

• plasma-core: 핵심 플라즈마 클라이언트 기능 - 논리의 이식 가능한 고기.

• plasma-node: plasma-coreCLI 구현을 위한 Node.js 래퍼

• plasma-js-lib: 플라즈마 트랜잭션을 통합하는 웹 애플리케이션 구축을 위한 JS 도우미입니다.

• plasma-contracts: The PlasmaChain.vy와 PlasmaRegistry.vyVyper의 계약.

• plasma-explorer: 운영자가 호스팅하는 블록탐색기.

• plasma-utils: 플라즈마 사양을 구축하기 위한 공유 유틸리티.

• plasma: 위 구성 요소에 대한 통합 테스트.

구현하는 아키텍처는 다음과 같습니다 plasma-core.

구현하는 아키텍처는 다음과 같습니다 plasma-chain-operator.

이 섹션에서는 프로토콜 구성 요소에 대한 용어와 직관을 다룹니다. plasma-utils이러한 데이터 구조는 '라이브러리' 에 의해 인코딩 및 디코딩됩니다 serialization. 각 구조에 대한 모든 데이터 구조의 정확한 바이트당 이진 표현은 스키마 에서 찾을 수 있습니다 .

코인ID 할당

플라즈마 자산의 기본 단위는 코인으로 표시됩니다. 표준 Plasma Cash와 마찬가지로 이 코인은 대체 불가능하며 코인의 인덱스를 coinID16바이트인 이라고 합니다. 자산(ERC 20/ETH) 기준으로 예치된 순서대로 할당됩니다. 특히 체인의 모든 자산은 ERC20 또는 ETH가 다르더라도 동일한 ID 공간을 공유합니다. tokenType즉, 모든 자산 클래스( 또는 라고 함 token)의 트랜잭션이 동일한 트리를 공유하여 최대 압축을 제공합니다.

처음 4바이트는 동전의 를 참조하고 tokenType다음 12바이트는 해당 특정 의 가능한 모든 동전을 나타내어 이를 달성합니다 tokenType.

예를 들어, 0번째 tokenType는 항상 ETH이므로 첫 번째 입금은 입금자에게 ETH코인에 대한 사용 권한을 부여합니다 .0x00000000000000000000000000000000

예금당 받는 총 코인은 정확히 (amount of token deposited)/(minimum token denomination)많습니다.

예를 들어, tokenType1이 이고 DAI, 동전 액면가가 이고 0.1 DAI, 첫 입금자가 을 보낸다고 가정해 봅시다 0.5 DAI. 즉 , 첫 번째 예금자는 최대 코인을 포함하여 s를 tokenType == 1받게 됩니다 .coinID0x000000010000000000000000000000000x00000001000000000000000000000004

실제로는 교단이 0.1. 액면가를 계약에 직접 저장하는 대신 예치된 금액 (또는 ETH의 경우)과 수신된 플라즈마 코인 수 사이의 소수점 자리 이동을 나타내는 decimalOffset각각의 매핑을 저장합니다. 이러한 계산은 스마트 계약 의 , 및 함수 에서 찾을 수 있습니다.tokenTypeERC20weidepositERC20depositETHfinalizeExit

//참고: decimalOfset이 릴리스에서는 s가 0으로 하드코딩됩니다. 클라이언트/운영자 코드에서 지원이 부족하기 때문입니다.

트랜스퍼

트랜잭션은 지정된 숫자와 트랜잭션의 각 범위에 대한 세부 정보를 설명하는 개체 block배열 로 구성됩니다. 스키마Transfer 에서 ( s 바이트):plasma-utilslength

https://gist.githubusercontent.com/ben-chain/2c3818f78846289a15be1aa175f35ca5/raw/04c7d06627c995b0641c792cf8fac9c12af16318/transfer.js

Transfera 의 각 항목 은 , , , 및 를 Transaction지정하는 것을 볼 수 있습니다 .tokenTypestartendsenderrecipient

형식화 및 형식화되지 않은 경계

start위에서 주목해야 할 한 가지는 및 end값이 s와 같은 16바이트가 아니라 12바이트라는 것입니다 coinID. 이는 예금에 대한 위 섹션의 맥락에서 이해되어야 합니다. coinID전송에 의해 설명된 실제 s를 얻기 위해 필드의 4바이트를 및 token왼쪽에 연결합니다 . 우리는 일반적으로 12바이트 버전을 's and' 라고 부르며 연결된 버전을 ' and' 라고 합니다 . 이러한 값은 serializer에서도 노출 됩니다 .startendtransferuntypedStartuntypedEndtypedStarttypedEnd

또 다른 참고 사항: 모든 전송에서 해당 s는 포함 및 배타적 coinID으로 정의됩니다 . 즉, 전송된 정확한 s는 입니다 . 예를 들어 처음 100개의 ETH 코인은 with , 및 와 함께 보낼 수 있습니다 . 두 번째 100은 및 .startendcoinID[typedStart, typedEnd)Transfertransfer.token = 0transfer.start = 0transfer.end = 100transfer.start = 100transfer.end = 200

스키마 Transaction는 4바이트 block숫자(트랜잭션은 특정 플라즈마 블록에 포함된 경우에만 유효함)와 객체 배열 로 구성됩니다 Transfer. 이것은 트랜잭션이 여러 전송을 설명할 수 있음을 의미하며, 이는 모두 원자적으로 실행되거나 전체 트랜잭션의 포함 및 유효성에 의존하지 않습니다. 이것은 이후 릴리스에서 분산 교환 및 조각 모음 의 기초를 형성할 것입니다 .

직렬화

위에 예시된 것처럼 plasma-utils데이터 구조에 대한 사용자 지정 직렬화 라이브러리를 구현합니다. JSON RPC와 스마트 계약은 모두 직렬 변환기에 의해 인코딩된 바이트 배열을 사용합니다.

인코딩은 매우 간단하며 스키마에 의해 정의된 바이트 수로 고정된 각 값을 연결합니다.

Transaction1개 이상의 s를 포함하는 객체 와 같이 가변 크기 배열을 포함하는 인코딩의 경우 Transfer단일 바이트가 요소 수 앞에 옵니다. 직렬화 라이브러리에 대한 테스트는 여기에서 찾을 수 있습니다 .

현재 다음 개체에 대한 스키마가 있습니다.

• Transfer

• UnsignedTransaction

• Signature

• SignedTransaction

• TransferProof

• TransactionProof

  3. 블록 구조 사양

  Plasma Cash가 도입한 가장 중요한 개선 사항 중 하나는 "라이트 프루프"였습니다. 이전에는 플라즈마 구성에서 사용자가 자금의 안전을 보장하기 위해 전체 플라즈마 체인을 다운로드해야 했습니다. Plasma Cash를 사용하면 자신의 자금과 관련된 Merkle 트리의 가지만 다운로드하면 됩니다.

  이것은 새로운 트랜잭션 유효성 조건을 도입하여 달성되었습니다 . 특정 트랜잭션은 Merkle 트리의 th 리프 coinID에서만 유효합니다 . 따라서 해당 코인에 대한 유효한coinID 트랜잭션이 존재 하지 않는다는 확신을 가지려면 해당 분기만 다운로드하는 것으로 충분합니다 . 이 방식의 문제는 트랜잭션이 이 액면가에 "고정"되어 있다는 것입니다. 여러 개의 코인을 트랜잭션하려면 각 리프에 하나씩 여러 트랜잭션이 필요합니다.

  안타깝게도 범위 기반 트랜잭션을 일반 Merkle 트리의 분기에 넣으면 라이트 증명이 안전하지 않게 됩니다. 하나의 분기가 있다고 해서 다른 분기가 교차하지 않는다는 보장이 없기 때문입니다.

일반 Merkle 트리에서 다른 분기가 교차하지 않도록 보장하는 유일한 방법은 모두 다운로드 하고 확인하는 것입니다. 그러나 그것은 더 이상 가벼운 증거가 아닙니다!

플라즈마 구현의 중심에는 새로운 블록 구조 와 수반되는 새로운 트랜잭션 유효성 조건이 있어 범위 기반 트랜잭션에 대한 가벼운 증명을 얻을 수 있습니다. 블록 구조는 머클 합계 트리라고 하며 각 해시 옆에는 sum값이 있습니다.

새 유효성 조건은 sum특정 분기의 값을 사용하여 aa start및 end범위를 계산합니다. 이 계산은 두 분기의 계산 범위가 겹치는 것이 불가능 하도록 특별히 제작되었습니다 . A는 transfer자신의 범위가 해당 범위 내에 있는 경우에만 유효하므로 라이트 클라이언트를 다시 얻을 수 있습니다!

이 섹션에서는 합계 트리의 정확한 사양, 실제로 범위 계산이 무엇인지, 범위 계산을 만족하는 트리를 실제로 구성하는 방법을 지정합니다. 이 사양으로 이끈 연구에 대한 자세한 배경과 동기는 이 게시물을 확인하세요.

우리는 플라즈마 머클 합계 트리의 두 가지 구현을 작성했습니다. 하나는 운영자를 위해 데이터베이스에서 수행되고 다른 하나 는 .plasma-utils

Merkle 합계 트리의 각 노드는 다음과 같이 48바이트입니다 [32 byte hash][16 byte sum] . sum의 16바이트 길이가 coinID!

이 두 부분을 끌어내는 두 개의 도우미 속성 .hash및 가 있습니다 . .sum예를 들어 일부의 경우 및 이 node = 0x1b2e79791f28c27ed669f257397e1deb3e522cf1f27024c161b619d276a25315ffffffffffffffffffffffffffffffff있습니다 . node.hash == 0x1b2e79791f28c27ed669f257397e1deb3e522cf1f27024c161b619d276a25315node.sum == 0xffffffffffffffffffffffffffffffff

일반 Merkle 트리에서 단일 루트 노드까지 해시 노드의 이진 트리를 구성합니다. 합계 트리 형식을 지정하는 것은 parent(left, right)두 형제를 인수로 받아들이는 계산 함수를 정의하는 간단한 문제입니다. 예를 들어 일반 Merkle 합계 트리에는 다음이 있습니다. 해시 함수는 parent = function (left, right) { return Sha3(left.concat(right)) } 어디에 있고 두 값을 함께 추가합니다.Sha3concat

Merkle 합계 트리를 생성하려면 parent함수는 자식 고유 .sum값에 대한 추가 작업의 결과도 연결해야 합니다.

부모 = 기능 (왼쪽, 오른쪽) { 
반환 Sha3(left.concat(right)).concat(left.sum + right.sum) 
}

예를 들어, 우리는

부모(0xabc…0001, 0xdef…0002) === 
해시(0xabc…0001.concat(0xdef…0002)).concat(0001 + 0002) === 
0x123…0003

는 해시뿐만 아니라 parent.hash각각에 대한 약속입니다 . 우리는 둘 다의 전체 96바이트를 해시합니다.sibling.sum

분기 범위 계산

머클 합계 트리를 사용하는 이유는 분기가 설명하는 특정 범위를 계산할 수 있고 다른 유효하고 겹치는 분기가 존재하지 않는다는 것을 100% 확신할 수 있기 때문입니다.

우리는 a를 더하고 가지를 위로 올라가서 leftSum이 범위를 계산합니다. rightSum각 상위 계산에서 둘 다 0으로 초기화하면 포함 증명이 오른쪽에 형제를 지정하면 를 취하고 rightSum += right.sum왼쪽에 있으면 를 추가합니다 leftSum += left.sum.

그런 다음 분기가 설명하는 범위는 [leftSum, root.sum — rightSum). 다음 예를 참조하십시오.

이 예에서 분기 6의 유효 범위는 입니다 [21+3, 36–5) == [24, 31). 31–24=7리프 6의 합계 값인 에 주목하십시오 ! 마찬가지로 분기 5의 유효 범위는 입니다 [21, 36-(7+5)) == [21, 24). 그 끝은 분기 6의 시작과 동일합니다!

가지고 놀아 보면 동일한 범위를 포함하는 두 개의 다른 가지로 Merkle sum 트리를 구성하는 것이 불가능하다는 것을 알 수 있습니다. 트리의 어떤 수준에서는 합계가 깨져야 합니다! 계속해서 범위(4.5,6)와 교차하는 다른 분기를 만들어 리프 5 또는 6을 "속이세요". 회색 상자에 s 만 입력 ?:

트리의 특정 수준에서는 항상 불가능하다는 것을 알 수 있습니다.

이것이 우리가 라이트 클라이언트를 얻는 방법입니다. 포함 증명에서 "암시적으로" 계산되기 때문에 분기 범위 범위를 implicitStart및 라고 부릅니다. 테스트 및 클라이언트 측 증명 확인을 위해 구현 implicitEnd된 분기 검사기가 있습니다 .plasma-utilscalculateRootAndBounds()

Vyper에서 스마트 계약을 통해

범위는 시작과 끝 으로 입력되며 전체 16바이트입니다.

일반 Merkle 트리에서 "잎"을 해싱하여 노드의 맨 아래 계층을 구성합니다.

우리의 경우 잎이 트랜잭션이 되기를 원합니다. 따라서 해싱은 간단하지만 여전히 .sum트리의 최하위 수준에 대한 값이 필요합니다.

txA단일 을 가진 일부가 주어지면 transferA합계 값은 무엇입니까? . _ _ transferA.end — transferA.start_ 그 이유는 전송이 닿지 않으면 가지의 범위를 망치기 때문입니다. 이 차이를 설명하기 위해 합계 값을 "채워야" 합니다. 그렇지 않으면 값이 root.sum너무 작아집니다.

흥미롭게도 이것은 간격의 오른쪽이나 왼쪽에 노드를 채울 수 있기 때문에 비결정적 선택입니다. 리프를 블록으로 구문 분석하기 위해 다음과 같은 "왼쪽 정렬" 방식을 선택했습니다.

.sum해당 분기 에 대한 최하위 값을 호출 parsedSum하고 스키마에는 최하위 노드를 재구성하는 데 사용되는 값이 TransferProof포함됩니다 ..parsedSum

따라서 스마트 컨트랙트에서 확인하는 브랜치의 유효 조건은 다음과 같습니다 implicitStart <= transfer.typedStart < transfer.typedEnd <= implicitEnd. "Plasma Cashflow" 합계 트리의 원래 디자인에서 일부 리프는 거래되지 않은 범위를 나타내기 위해 특수한 "NoTx" 트랜잭션으로 채워졌습니다. 이 형식을 사용하면 거래되지 않는 코인은 단순히 범위 [implicitStart, transfer.typedStart)및 [transfer.typedEnd, implicitEnd). 스마트 계약은 이 범위의 어떤 코인도 출구에 대한 도전이나 응답에 사용할 수 없도록 보장합니다.

종종 (거래 수수료 및 교환을 지원하기 위해) 거래는 유효하기 위해 원자적으로 발생하거나 발생하지 않는 다중 전송을 요구합니다. 그 효과 는 유효한 거래가 .transfers각각에 대해 한 번씩 포함되어야 한다는 것입니다 . 그러나 이러한 각 포함에 대해 여전히 맨 아래까지 파싱되는 것은 개인이 아닌 전체 의 해시입니다 .transfer.typedStart.typedEndUnsignedTransactionTransfer.hash

기존의 블록체인 시스템과 달리 전체 플라즈마 노드는 모든 단일 트랜잭션을 저장하지 않고 자신이 소유한 자산과 관련된 정보만 저장하면 됩니다. 이것은 보낸 사람이 실제로 주어진 범위를 소유하고 있음을 증명 해야sender 함 을 의미합니다. 완전한 증명에는 이더리움 체인 자체가 분기되지 않는 경우 메인 체인에서 토큰을 교환할 수 있음을 보장하기에 충분한 모든 정보가 포함되어 있습니다.recipient

증명은 주로 해당 코인에 대한 관리 체인을 업데이트하는 트랜잭션의 포함 및 비포함으로 구성됩니다. 포함 루트는 운영자가 메인 체인의 스마트 계약에 제출한 블록 해시와 비교하여 확인해야 합니다. 토큰의 최초 예치금부터 계약에 이르기까지 증명 체계에서 검증된 대로 관리 사슬을 추적함으로써 상환 능력이 보장됩니다.

plasma-core들어오는 트랜잭션 증명을 확인하기 위한 비교적 간단한 방법론을 따릅니다. 이 섹션에서는 해당 방법론에 대해 설명합니다.

역사 증명은 일련의 예금 기록 과 Transaction해당 s가 있는 관련 s 의 긴 목록으로 구성됩니다 TransctionProof.

plasma-utils 에 대한 호출을 통해 여기static checkTransactionProof(transaction, transactionProof, root) 에서 사용되는 메서드를 노출 합니다 .plasma-core ProofService

개체 TransactionProof에는 주어진 의 유효성을 확인하는 데 필요한 모든 정보가 포함되어 있습니다 Transaction. 즉, 단순히 객체 의 배열 입니다 TransferProof. Atomic multisends에 대한 위의 섹션에 따라 주어진 TransactionProof모든 것이 유효한 경우에만 유효합니다 TransferProofs.

TransferProofs올바른 블록 번호 Transfer에서 제공된 에 해당하는 유효한 분기 포함을 복구하는 데 필요한 모든 필수 정보를 포함합니다 . Transaction이는 다음을 구성합니다.

• 분기의 전체 'inclusionProof'를 나타내는 Merkle 합계 트리의 실제 노드

• 분기가 추적하는 이진 경로를 계산하기 위한 잎의 인덱스

• .sum위의 합계 트리 사양에 설명된 대로 구문 분석된 하단

• signature특정 발신자에 대한 입니다 .

plasma-utils 스키마 에서 바로 :

는 inclusionProof크기가 트리의 깊이에 따라 달라지는 가변 길이 배열입니다.

검증 프로세스의 핵심은 입금부터 시작하여 각 증명 요소를 현재 "검증된" 상태에 적용하는 것입니다. 증명 요소가 유효한 상태 전환을 초래하지 않으면 증명을 거부해야 합니다.

각 증명 요소를 적용하는 프로세스는 직관적입니다. 계약의 보관 규칙에 따라 각 블록에 트랜잭션을 적용하기만 하면 됩니다.

역사적으로 소유된 범위를 추적하는 방법을 snapshot. 간단히 말해서 블록에서 확인된 범위 소유자를 나타냅니다.

수신된 모든 범위는 해당 보증금에서 가져와야 합니다. 예금 레코드는 token, start, end, depositer및 로 구성됩니다 blockNumber.

각 입금 기록에 대해 검증자는 청구된 입금이 실제로 발생했는지 확인하고 그 동안 어떠한 종료도 발생하지 않았는지 확인하기 위해 이더리움을 다시 확인해야 합니다 .

그렇다면 배열은 각각 이 예금자인 verifiedSnapshots이러한 예금으로 초기화됩니다 .snapshot.owner

TransactionProof다음으로 주어진 s를 모두 적용하고 verifiedSnapshots그에 따라 업데이트합니다. 각 transaction해당 에 대해 transactionProof검증자는 다음 단계를 수행합니다.

1. 주어진 증명 요소가 유효한지 확인하십시오. 그렇지 않은 경우 오류를 발생시킵니다.

2. transfer의 각각에 대해 transaction다음을 수행합니다 . transfer.typedStart, transfer.typedEnd, implicitStart및 implicitEnd b 에서 위에서 업데이트된 모든 스냅샷을 "분할"합니다 . c 와 같은 모든 .block결과에 대해 숫자를 증가시킵니다 . 와 사이에 있는 각 분할에 대해 : i. 확인하십시오 . 그렇지 않은 경우 오류를 발생시킵니다. ii. 설정합니다 .verifiedSnapshotsblocktransaction.blockNumber — 1 snapshottransfer.starttransfer.end snapshot.owner === transfer.from snapshot.owner = transfer.sender

는 TransactionProofs오름차순으로 적용해야 합니다 blockNumber.

이 작업이 모든 에 대해 재귀적으로 적용되면 TransactionProof클라이언트는 현재 플라즈마 블록 verifiedSnapshots과 blockNumber동일한 모든 요소와 owner주소가 동일한 모든 요소를 ​​검색하여 현재 소유하고 있는 새로운 코인을 확인할 수 있습니다.

위 1단계의 트랜잭션 유효성 검사는 스마트 계약의 유효성 조건을 검사하는 것과 같습니다. 위의 합계 트리 사양을 기반으로 한 기본 유효성 검사는 다음과 같습니다.

1. 트랜잭션 인코딩이 올바른 형식인지 확인합니다.

2. 각 transfer해당 항목 에 대해 transferProof: a. 가 해당 주소 signature로 확인되는지 확인합니다 . b. c에 의해 정의된 이진 경로를 사용하여 해당 플라즈마 블록에 대한 루트 해시와 동일한 루트가 있는지 확인합니다 . 분기의 and를 계산 하고 다음을 확인합니다.transfer.sender inclusionProofleafIndex implicitStartimplicitEndimplicitStart <= transfer.start < transfer.end <= implicitEnd

   4.계약 및 종료 게임

   물론 자금을 안전하게 유지하기 위해 메인 체인으로 전달될 수 없다면 관리 사슬에 대한 증거는 유용하지 않습니다. 온체인에서 증명을 받아들이는 메커니즘은 플라즈마의 보안 모델의 핵심이며, 이를 "엑시트 게임"이라고 합니다.

   사용자가 플라즈마 체인에서 돈을 옮기고 싶을 때 분쟁 기간을 여는 "출구"를 만듭니다. 분쟁 기간이 끝날 때 미해결 분쟁이 없으면 메인 체인의 플라즈마 계약에서 종료자에게 돈이 전송됩니다. 분쟁 기간 동안 사용자는 퇴출되는 돈이 퇴장하는 사람의 정당한 소유가 아니라고 주장하는 "도전"을 제출할 수 있습니다. 위에서 설명한 증명은 이러한 문제에 대한 "응답"이 항상 계산 가능함을 보장합니다.

   출구 게임의 목표는 최대한 적대적인 운영자의 경우에도 돈을 안전하게 유지하는 것입니다. 특히 완화해야 하는 세 가지 주요 공격이 있습니다.

   • 데이터 보류: 운영자는 계약에 루트 해시를 게시할 수 있지만 블록의 내용이 무엇인지 누구에게도 알리지 않습니다.

   • 위조/무효 트랜잭션 포함sender : 운영자는 이전 recipient에 Chain of Custody 가 아닌 블록에 트랜잭션을 포함할 수 있습니다 .

   • 검열: 누군가가 돈을 입금한 후 운영자는 돈을 보내는 모든 거래를 게시하는 것을 거부할 수 있습니다.

   이 모든 경우에 종료 게임의 챌린지/응답 프로토콜은 최대 1개의 챌린지와 1개의 응답에서 이러한 동작이 절도를 허용하지 않도록 합니다.

입금 매핑

다시, 우리는 범위의 시작에 액세스하기 위해 호출할 수 있도록 키 tokenType와 함께 이중 중첩 매핑을 사용합니다 . Vyper는 설정되지 않은 모든 매핑 키에 대해 0을 반환하므로 사용자가 설정되지 않은 을 전달하여 계약을 "속일" 수 없도록 bool이 필요합니다 .untypedEndself.exitable[tokenType][untpyedEnd].untypedStartisSetexitableRange

계약의 범위는 이라는 도우미 함수를 통한 self.exitable성공적인 호출에 따라 분할 및 삭제됩니다 . 이전에 종료된 범위의 종료는 챌린지할 필요조차 없습니다. 그들은 결코 시험을 통과하지 못할 것입니다 . 여기에서 해당 코드를 찾을 수 있습니다 .finalizeExitremoveFromExitablecheckRangeExitablefinalizeExit

Exit 게임과 바닐라 플라즈마 캐시의 관계 본질적으로 우리 사양의 종료 게임은 원래 Plasma Cash 디자인과 매우 유사합니다. 종료는 함수 호출로 시작됩니다.

beginExit(tokenType: uint256, blockNumber: uint256, untypedStart: uint256, untypedEnd: uint256) -> uint256: 종료에 대해 이의를 제기하기 위해 모든 챌린지는 특정 coinID질문을 지정하고 플라즈마 캐시 스타일 챌린지 게임은 특정 코인에 대해 수행됩니다. 전체 퇴장을 취소하려면 단 하나의 코인만 유효하지 않은 것으로 입증되어야 합니다.

출구와 응답 가능한 두 가지 유형의 도전에는 exitID및 challengeID증가를 통해 순서대로 할당되는 및 가 challengeNonce지정 됩니다 exitNonce.

블록번호 지정 트랜잭션 원래 Plasma Cash 사양에서 종료자는 운영자가 유효한 트랜잭션 포함을 지연하고 유효하지 않은 트랜잭션을 블록 사이에 삽입하는 "인플라이트" 공격을 방지하기 위해 종료된 트랜잭션과 이전 "상위" 트랜잭션을 모두 지정해야 합니다. .

트랜잭션에 여러 부모가 있을 수 있기 때문에 범위 기반 체계에 문제가 있습니다. 예를 들어 Alice가 Carol에게 보내고 Bob이 Carol에게 (0, 50]보낸다면 Carol은 이제 Dave에게 보낼 수 있습니다. 그러나 Dave가 종료하려는 경우 및 둘 다 부모 입니다.(50, 100](0, 100](0, 50](50, 100]

여러 부모를 지정하는 것은 확실히 가능하지만 이 사양은 비용이 많이 들고 구현하기가 더 복잡해 보였습니다. 그래서 우리는 더 간단한 대안을 선택했습니다. 각 트랜잭션은 발신자가 의도한 '블록'을 지정하고 다른 블록에 포함된 경우 무효화됩니다. 이것은 기내 공격을 해결하고 계약에 트랜잭션의 부모가 필요하지 않음을 의미합니다. 이 체계에 대한 공식적인 문서 작성 및 안전 증명에 관심이 있는 사람들은 이 훌륭한 게시물을 살펴볼 가치가 있습니다 .

코인별 거래 유효성 먼저 주목할 가치가 있는 출구 게임의 직관적이지 않은 속성은 특정 트랜잭션이 해당 범위의 일부 코인에 대해 "유효"할 수 있지만 다른 코인에 대해서는 유효하지 않을 수 있다는 것입니다.

예를 들어 Alice가 (0, 100]Bob에게 전송하고 Bob이 (50, 100]Carol에게 전송한다고 가정합니다. Carol은 Alice가 전체 의 정당한 소유자인지 확인할 필요가 없습니다(0, 100] . Carol은 Alice가 소유한 보증 (50, 100], 즉 그녀의 영수증에 적용되는 보관 체인의 일부만 필요로 합니다. Alice가 를 소유하지 않은 경우 트랜잭션이 어떤 의미에서 "무효"일 수 있지만 (0, 50]스마트 계약은 코인에 대한 출구와 관련된 분쟁의 목적으로 이를 신경 쓰지 않습니다(50, 100] . 받은 코인의 소유권이 확인되는 한 나머지 거래는 중요하지 않습니다.

이것은 라이트 클라이언트 증명의 크기를 유지하기 위한 매우 중요한 요구 사항입니다. Carol이 full 을 확인해야 하는 경우 의 겹치는 상위 항목을 확인 하고 모든 상위 항목을 (0, 100]확인해야 할 수도 있습니다 . (0, 10000]이 "계단식" 효과는 트랜잭션이 매우 상호 의존적인 경우 증명의 크기를 엄청나게 증가시킬 수 있습니다.

이 속성은 교환되는 여러 범위를 설명하는 원자적 다중 전송에도 적용됩니다. Alice가 1 ETH를 Bob의 1 DAI와 거래하는 경우 서명하기 전에 Bob이 1 Dai를 소유하고 있는지 확인하는 것은 Alice의 책임입니다. 그러나 이후 Bob이 1 ETH를 Carol에게 보낸다면 Carol은 Bob이 1 DAI를 소유했는지 확인할 필요 없이 Alice가 Bob에게 보낸 1 ETH를 소유했다는 사실만 확인할 필요가 있습니다. Alice가 위험을 감수했으므로 Carol은 그럴 필요가 없습니다.

스마트 계약의 관점에서 볼 때 이 속성은 coinID출구 내 특정 항목에 대해 항상 제출되는 문제의 직접적인 결과입니다.

계약에서 트랜잭션 확인을 처리하는 방법 종료 게임에서 사용하려면 s 가 위의 증명 섹션(유효한 서명, 분기 경계 등)에 설명된 검사를 Transaction통과해야 합니다 . TransactionProof이 검사는 함수의 계약 수준에서 수행됩니다.

여기서 중요한 사항은 transferIndex논증입니다. 트랜잭션에는 여러 전송이 포함될 수 있으며 각 전송에 대해 트리에 한 번씩 포함되어야 합니다. 그러나 챌린지는 특정 을 참조하므로 coinID단일 전송만 관련됩니다. 따라서 챌린저와 리스폰더는 transferIndex이의를 제기하는 코인과 관련된 전송을 제공합니다. 검사는 TransferProof의 모든 s를 디코딩하고 검사 TransactionProof한 다음 함수를 사용하여 각각에 대한 포함을 검사합니다.

def checkTransferProofAndGetTypedBounds( leafHash: bytes32, blockNum: uint256, transferProof: bytes[1749] ) -> (uint256, uint256): # typedimplicitstart, typedimplicitEnd 모든 s가 확인되면 th TransferProof에 대한 분쟁 관련 값이 게임 종료 기능, 즉 , , , 및 로 반환됩니다 .transferIndexTransfersenderrecipienttypedStarttypedEndplasmaBlockNumber

이를 통해 종료를 위한 전체 챌린지/응답 게임 세트를 지정할 수 있습니다.

종료를 즉시 취소하는 챌린지 두 종류의 챌린지는 퇴장을 즉시 취소합니다: 사용된 코인에 대한 도전과 예치금이 발생하기 전에 퇴장한 도전.

소비된 코인 챌린지 이 챌린지는 트랜잭션 종료자가 이미 다른 사람에게 코인을 보냈음을 증명하는 데 사용됩니다.

@public def challengeSpentCoin( exitID: uint256, coinID: uint256, transferIndex: int128, transactionEncoding: bytes[277], transactionProofEncoding: bytes[1749], ): 다음을 사용 checkTransactionProofAndGetTypedTransfer하고 확인합니다.

챌린지된 coinID는 지정된 출구 내에 있습니다. 챌린지된 coinID는 의 th 요소 typedStart및 에 있습니다 .typedEndtransferIndextransaction.transfers plasmaBlockNumber출구보다 도전이 더 크다 . transfer.sender출구입니다 . 아토믹 스왑의 도입은 한 가지를 의미합니다. 운영자가 둘 이상의 당사자 간에 아토믹 스왑을 보류하는 극단적인 경우 때문에 사용된 코인 챌린지 기간은 다른 것보다 엄격하게 짧아야 합니다. 이 경우 해당 당사자는 사전 스왑된 코인을 종료해야 하며 운영자는 사용된 코인 챌린지를 수행하고 스왑이 포함되었는지 여부를 밝혀야 합니다. 그러나 운영자가 마지막 순간에 그렇게 하도록 허용하면 당사자가 공개를 사용하여 다른 종료를 취소할 시간이 없는 경합 상태가 됩니다. 따라서 시간 초과는 일반 챌린지 창보다 짧아(1/2) "마지막 순간 응답" 공격을 제거합니다.

입금 챌린지 이전 이 챌린지는 해당 코인이 실제로 입금된 것보다 일찍 출구가 발생했음을 입증하는 데 사용됩니다 .plasmaBlockNumber

@public def challengeBeforeDeposit( exitID: uint256, coinID: uint256, depositUntypedEnd: uint256 ): self.deposits[self.exits[exitID].tokenType][depositUntypedEnd].precedingPlasmaBlockNumber컨트랙트는 엑시트의 블록 번호보다 이후인지 조회 하고 확인합니다. 그렇다면 취소됩니다.

낙관적 출구 및 포함 문제 우리의 계약은 낙관적인 경우에 포함 확인을 전혀 수행하지 않고 종료가 발생하도록 허용합니다. 이를 허용하기 위해 모든 출구는 다음을 통해 직접 도전할 수 있습니다.

@public def ChallengeInclusion(exitID: uint256): 퇴출자는 퇴출하려는 거래 또는 입금으로 직접 응답해야 합니다.

@public def respondTransactionInclusion( ChallengeID: uint256, transferIndex: int128, transactionEncoding: 바이트[277], transactionProofEncoding: 바이트[1749], ): ... @public def respondDepositInclusion( ChallengeID: uint256, depositEnd: uint256 ): 두 번째 경우는 운영자가 입금 후 모든 거래를 검열한 경우 사용자가 돈을 인출할 수 있습니다.

다음과 같은 경우 두 응답 모두 챌린지를 취소합니다.

입금 또는 거래는 실제로 출구의 플라즈마 블록 번호에 있었습니다. 예금자 또는 수령인은 실제로 출구입니다. 출금의 시작과 끝이 입금이나 이체의 시작과 끝 안에 있었다 잘못된 역사 챌린지 바닐라 플라즈마 캐시와 이 사양 모두에 대해 가장 복잡한 도전-응답 게임은 역사 무효의 경우입니다. 프로토콜의 이 부분은 발신자가 이전 수신자가 아닌 위조된 "잘못된" 트랜잭션을 운영자가 포함하는 공격을 완화합니다. 그 해결책을 유효하지 않은 기록 챌린지라고 합니다. 정당한 소유자가 아직 코인을 사용하지 않았기 때문에 그들은 이를 증명하고 다음과 같이 도전합니다. 글쎄, 그것은 이전에 내 것이었고 내가 그것을 사용한 적이 있다는 것을 증명할 수 없습니다.”

유효하지 않은 기록 챌린지 및 응답은 모두 입금 또는 거래일 수 있습니다.

도전적인

현재 정당한 소유자에 따라 두 가지 방법으로 이의를 제기할 수 있습니다.

@public def challengeInvalidHistoryWithTransaction( exitID: uint256, coinID: uint256, transferIndex: int128, transactionEncoding: bytes[277], transactionProofEncoding: bytes[1749] ): 그리고

@public def challengeInvalidHistoryWithDeposit( exitID: uint256, coinID: uint256, depositUntypedEnd: uint256 ): 이 둘은

@private def challengeInvalidHistory( exitID: uint256, coinID: uint256, claimant: address, typedStart: uint256, typedEnd: uint256, blockNumber: uint256 ): coinID이 시도된 종료 내에 있고 이 blockNumber종료보다 이전인지 확인하는 작업을 수행하는 기능입니다 .

유효하지 않은 기록 문제에 대응

물론 유효하지 않은 히스토리 챌린지는 실제로 챌린저가 코인을 사용하고 관리 체인이 실제로 유효한 경우 슬픔일 수 있습니다. 우리는 이 응답을 허용해야 합니다. 두 종류가 있습니다.

첫 번째는 도전자의 지출을 보여주는 트랜잭션으로 응답하는 것입니다.

@public def respondInvalidHistoryTransaction( ChallengeID: uint256, transferIndex: int128, transactionEncoding: 바이트[277], transactionProofEncoding: 바이트[1749], ): 그런 다음 스마트 계약은 다음 확인을 수행합니다.

의 제 transferIndex는 도전 을 다룹니다 .TransfertransactionEncodingcoinID transferIndexth는 실제로 transfer.sender그 잘못된 역사 도전에 대한 청구인이었습니다. 트랜잭션의 플라즈마 블록 번호는 유효하지 않은 기록 챌린지와 종료 사이에 있습니다. 다른 응답은 코인이 실제로 예치되기 전에 챌린지가 왔다는 것을 보여주는 것입니다. 즉, 챌린지를 무효화하는 것입니다. 이는 challengeBeforeDepositfor 종료 자체와 유사합니다.

@public def respondInvalidHistoryDeposit( ChallengeID: uint256, depositUntypedEnd: uint256 ): 이 경우 챌린지가 유효하지 않기 때문에 보낸 사람이 챌린지 수신자인지 확인하지 않습니다. 따라서 계약은 다음을 확인해야 합니다.

보증금은 도전을 다룹니다 coinID. 보증금의 플라즈마 블록 번호는 도전과 출구 사이에 있습니다. 그렇다면 종료가 취소됩니다.

이것으로 완전한 종료 게임 사양을 마칩니다. 이러한 빌딩 블록을 사용하면 최대한 악의적인 플라즈마 체인의 경우에도 자금을 안전하게 유지할 수 있습니다.

구현에서 누락된 부분 Automated Guarding 시작은 좋았지만 이 사양과 그 이상에서 Plasma의 진정한 잠재력을 실현하려면 많은 개선이 필요합니다. 현재 구현에서 가장 눈에 띄게 누락된 부분은 사용자를 대신하여 챌린지 및 응답을 제출하는 자동화된 프로세스인 보호입니다. 고맙게도 출구 게임 자체가 구현되고 수동으로 테스트 되었으므로 체인이 배포된 후 클라이언트 소프트웨어를 업데이트할 수 있습니다. 우리는 이것이 테스트넷 릴리스에 충분하다고 느꼈지만 코드에 필요한 가장 시급한 추가 사항입니다.

P2P 이력 증명

현재 사용자가 거래를 받으면 운영자에게 요청하고 전체 증명을 다시 다운로드합니다. 이로 인해 운영자 오버헤드가 크게 증가합니다. 실제로 발생해야 하는 것은 발신자가 로컬에 저장된 증거를 수신자에게 직접 전송하여 운영자를 우회하고 플라즈마 체인을 실행하는 데 훨씬 저렴하게 만드는 것입니다.

조각 모음 전략 원자 스왑을 지원하므로 현재 사양은 계약을 업그레이드하지 않고도 모든 조각 모음 전략과 호환됩니다. 그러나 특히 플라즈마 블록 번호를 지정하기 위해 트랜잭션이 필요하기 때문에 올바른 접근 방식이 무엇인지는 여전히 남아 있습니다. 우리는 플라즈마 커뮤니티가 운영자와 사용자가 다양한 접근 방식을 시도할 수 있는 확장 가능한 조각 모음 추상화 라이브러리를 구축할 수 있기를 바랍니다.

프런트엔드 지갑 통합 프런트엔드 지갑에 대한 몇 가지 디자인이 있지만 현재 클라이언트는 다른 ERC20 거래를 지원하지 않고 명령줄 거래만 지원합니다. 테스트넷 사용자에게 멋진 UI를 제공하는 것은 UX 및 접근성 측면에서 중요한 단계가 될 것입니다.

운영자 수수료 Atomic multisend를 지원하기 때문에 프로토콜 수정 없이 거래 수수료를 지원할 수 있습니다. 그러나 현재 이 테스트넷 출시를 위해 구현된 것은 없습니다.

네트워크 운영자 우리가 아직 활용하지 못하고 있는 것은 머클 트리 구성이 고도로 병렬화 가능하다는 것입니다. 운영자가 네트워크 클러스터로 배포된 경우 하위 트리를 병렬로 구성하여 블록 크기를 늘릴 수 있습니다.

코드 검토 현재 모든 클라이언트, 계약 및 운영자 구현에 치명적인 버그가 있을 가능성 이 매우 높습니다 . 이 공개 출시의 일부가 외부 기여자가 많은 실수를 지적하는 데 도움이 되는 기회가 되기를 바랍니다!

사양의 누락된 부분 Succinct Proof Schemes 서론에서 언급했듯이 플라즈마 연구에서 가장 활발한 분야는 이력 증명 크기를 줄이기 위한 계획입니다. P2P 여부와 관계없이 오래된(예: 1년 이상) 코인에는 상당한 양의 관련 증명 데이터가 있어 거래가 번거로울 수 있습니다. 이력 증명에는 최소한 블록당 하나의 분기가 포함되어 있기 때문입니다.

RSA 누산기 구성과 여러 블록에 걸쳐 분기 증명을 배치하는 STARKS/SNARKS가 현재 가장 유력한 후보입니다. 둘 다 프로토콜 변경이 필요합니다. RSA(신뢰할 수 있는 설정도 도입)의 경우 완전히 새로운 유효성 조건을 종료 게임에 추가해야 합니다. 후자의 경우 EVM에서 구현되지 않은 SNARK/STARK 친화적 해싱 알고리즘을 사용하여 트리를 구성해야 합니다.

대량 퇴출/입금 체계 운영자가 악의적으로 변하면 사용자는 (결국 서두를 필요 없이!) 자금을 퇴출해야 합니다. 단일 온체인 트랜잭션을 통해 많은 사용자가 함께 탈퇴하는 데 동의하는 "대량 탈퇴"의 개념은 상당한 확장성 증가가 될 것입니다. 이상적으로, 출구는 잔고의 머클 루트를 통해 자금을 다른 플라즈마 체인에 직접 자동 예치할 수 있습니다. 이를 통해 많은 사용자가 메인 체인에서 개별 잔액을 해결하지 않고도 체인을 전환할 수 있습니다. 이는 여러 플라즈마 체인의 "네트워크 가능성"을 크게 향상시킵니다.

다중 운영자 네트워크 운영자는 자금을 훔칠 수 없지만 마음대로 거래를 검열할 수 있습니다. 이에 대한 한 가지 완화 방법은 단일 운영자 모델을 일련의 운영자로 대체하여 정직한 운영자 한 명만으로도 고객이 거래할 수 있도록 하는 것입니다.

종료 기록 개선 종료 가능한 범위 구성을 통해 종료된 범위에 대한 일정한 크기의 검사가 가능합니다. 그러나 각 종료가 이 매핑을 업데이트하므로 동일한 범위의 종료가 오름차순으로 처리되지 않으면 경쟁 조건이 발생합니다. 이는 첫 번째 종료의 종료가 범위를 분할하여 매핑에 대한 키를 변경 self.exitable하고 checkRangeExitable분할되지 않은 범위를 참조하는 종료가 실패하도록 하기 때문입니다. 이러한 종료는 되돌아가고 다음 이더리움 블록에서 다시 제출해야 합니다. 어떤 종류의 트리, 대기열 또는 일부 방법을 사용하는 가스 효율적인 대안이 존재할 수 있습니다 batchFinalizeExits.

상태 채널 및 스크립팅 최근 연구 커뮤니티에서 상태 채널 및 언약이 포함된 스크립팅이 Plasma에서 가능하다고 제안하는 몇 가지 큰 진전이 있었습니다. 현재 사양은 이러한 기능을 지원하지 않으며 지원하려면 스마트 계약을 크게 업그레이드해야 합니다.

함께, 우리는 보다 분산된 미래의 비전을 실현하기 위해 구축할 것입니다.