우리는 최근 보다 일반화된 플라즈마 아키텍처 에 대한 우리의 새로운 작업을 설명하는 기사를 게시했습니다 . 이 게시물은 내부에서 작동하는 방식에 관심이 있는 사람들을 위해 아키텍처에 대해 자세히 설명합니다. 상위 수준에서 모든 것이 어떻게 결합되는지 살펴본 다음 Python의 샘플 구현 으로 건너뛸 것입니다. 플라즈마에 대해 이미 잘 알고 있는 경우 다이어그램으로 스크롤할 수 있습니다.

이전 기사의 주요 내용은 다음과 같습니다.

1. 플라즈마 연구를 따라가는 것은 어렵습니다. 플라즈마에 익숙한 사람들은 다양한 플라즈마 맛에 대해 들어봤을 것입니다. 각 맛에는 서로 다른 장단점이 있으며 빠르게 진화하는 연구를 따라가는 것은 정규직입니다.

2. 대부분의 개발자는 dapp을 확장하는 간단하고 쉬운 방법을 원합니다. 사람들은 좋은 도구와 잘 문서화된 라이브러리를 원합니다. 그들은 확실히 단일 앱을 실행하기 위해 처음부터 전체 블록체인을 구축하기를 원하지 않습니다.

그래서 우리는 플라즈마 전문가가 아니어도 확장 가능한 블록체인 애플리케이션을 쉽게 구축할 수 있는 플랫폼을 만들기 시작했습니다. 우리는 앱(또는 "플랩")을 구축할 수 있는 범용 플라즈마 체인으로 끝났습니다. 아직 이상하게 들리나요? 플랩. Plaaapp. 플랩. 예.

"레이어 2"의 핵심 아이디어는 메인 블록체인 외부의 데이터("오프체인 데이터")를 사용하여 메인 블록체인에 있는 자산("온체인 데이터")에 대한 보증을 제공할 수 있다는 것입니다. 예를 들어, 해당 오프체인 데이터는 이더리움의 온체인 에스크로 계약에 보관된 자산을 인출할 수 있는 권리를 부여할 수 있습니다. 그러나 그 자산의 소유권은 이더리움을 건드리지 않고 손이 바뀌었습니다.

물론 오프체인 데이터는 결국 메인 블록체인에서 어떤 일이 일어날 가능성이 없다면 유용하지 않습니다. 이것은 일반적으로 사용자가 오프체인 데이터에 대한 "클레임"을 청구되는 자산이 보관된 온체인 스마트 계약에 제출하도록 허용함으로써 달성됩니다. 이 주장은 "자산 X를 인출할 수 있다는 서명된 메시지가 있습니다."와 같은 것일 수 있습니다.

그러나 클레임을 제출한 후 앞서 언급한 클레임을 한 사람이 다른 사람 에게 자산 X를 보내는 메시지를 노래하면 어떻게 됩니까 ? 이것은 위의 철회를 무효화합니다. 이러한 유효하지 않은 철회가 실패하지 않도록 모든 청구에 분쟁 기간을 추가합니다. 누구나 분쟁 기간이 끝나기 전에 청구에 이의를 제기할 수 있습니다. 그렇지 않으면 청구가 유효한 것으로 간주됩니다. 충분히 간단합니다!

이것을 다시 플라즈마와 빠르게 연관시키겠습니다. 플라즈마 체인은 일련의 블록으로 구성되며 각 블록은 일련의 트랜잭션으로 구성됩니다. 새로운 플라즈마 체인 블록이 생성될 때마다 해당 블록에 대한 암호화 커밋이 메인 체인에 게시됩니다. 이러한 커밋은 해당 블록 내부에 무언가가 있음을 증명하는 데 사용할 수 있습니다. 우리의 경우 이 커밋은 블록의 모든 상태 업데이트에서 생성된 머클 루트입니다.

이더리움의 플라즈마 스마트 계약은 운영자가 플라즈마 블록을 커밋한 순서를 기록하고 커밋을 덮어쓰는 것을 방지합니다.따라서 이러한 블록 커밋은 우리에게 시간 감각을 제공합니다. 사용자가 플라즈마 체인에서 발생한 일에 대해 주장을 하고 싶을 때 블록 번호를 통해 해당 일이 발생한 시기 도 참조해야 합니다 . 예를 들어, 사용자는 "여기 에 자산 Z를 제공한 블록 Y의 트랜잭션 X가 있습니다."라고 말할 수 있습니다. 이 추가 시간 차원은 분쟁에 있어서도 중요합니다. 어떤 일이 다른 일 이전에 일어났는지 이후에 일어났는지 알고 싶을 때가 있기 때문입니다!

추상적인 오프체인 데이터주의

방금 본 것처럼 레이어 2는 주로 일부 오프체인 데이터를 사용하여 온체인에 있는 것에 영향을 주는 것입니다. 지금까지 오프체인 데이터는 소유권을 나타내는 데 주로 사용되었습니다 . 누가 무엇을 소유하고 있는지, 소유권이 바뀌었는지 여부입니다.

Alice는 Ethereum의 스마트 계약에 자산을 예치하고 해당 자산의 소유자가 됩니다. 그런 다음 그녀는 자산 소유권을 Bob에게 이전하는 오프체인 메시지에 서명할 수 있습니다. 그런 다음 Bob은 서명된 메시지를 사용하여 청구함으로써 Ethereum에서 자산을 다시 인출할 수 있습니다.

우리는 또한 소유권보다 더 복잡한 것을 나타낼 수 있습니다. 앨리스가 크립토키티를 입금하고 키티의 털 색깔을 바꾸는 여러 메시지에 서명했다고 가정해 봅시다. 위의 예에서와 같이 그녀는 결국 그녀가 서명한 마지막 메시지를 사용하여 새끼 고양이의 털 색깔에 대해 이더리움에서 주장할 수 있습니다!

새끼 고양이의 털 색깔이나 눈 색깔이 바뀌든 이더리움의 스마트 계약은 이러한 변화를 이해할 수 있는 방법이 필요합니다. 각각의 새로운 기능 또는 새로운 유형의 "상태 전환"에는 플라즈마 계약이 뒤따르는 논리의 변경이 필요합니다. 이전 플라즈마 사양에서 이와 같은 기능을 추가하면 *전체* 플라즈마 계약을 재배포하고 모든 사람의 자산을 이전 플라즈마 체인에서 새 것으로 마이그레이션해야 함을 의미했습니다. 이는 안전하거나 확장 가능하거나 업그레이드할 수 없습니다.

우리는 새로운 기능을 추가하고자 하는 플라즈마 체인 설계에 충분히 도달한 후 이 업그레이드 가능성 문제에 부딪쳤습니다. 약간의 브레인스토밍 후에 우리는 주요 플라즈마 체인 계약을 변경하지 않고 새로운 기능을 추가하는 쉬운 방법이 있다는 것을 깨달았습니다.

지금까지 이야기한 다양한 시나리오에는 공통점이 있습니다. 오프체인 데이터는 항상 잘못된 온체인 주장을 "논쟁"하기 위한 것입니다. 특정 클레임에 대한 분쟁은 기본적으로 클레임에 언급된 상태가 구식이라는 증거일 뿐입니다. 소유권 분쟁은 소유권 주장을 한 사용자가 나중에 다른 사람에게 소유권을 이전했음을 증명합니다. 고양이 털 색상에 대한 분쟁은 고양이 털 색상이 변경되었음을 증명해야 합니다.

우리의 주요 돌파구는 분쟁 조건이 기본 스마트 계약에서 확인할 필요가 없다는 것을 깨닫는 것이었습니다. 대신, 분쟁이 유효한지 여부를 알려주는 기능을 구현하는 다른 스마트 계약을 가질 수 있습니다. 해당 기능에 필요한 논리를 구현한 새 계약을 생성하여 새 기능을 추가한 다음 기본 계약이 새 계약을 참조하도록 할 수 있습니다. 이러한 외부 계약을 '술어' 라고 합니다 .

이제 새 기능을 추가하는 것은 정말 쉬웠지만 여전히 특정 상태 업데이트에 사용할 술어를 알 수 있는 방법이 필요했습니다. 새끼 고양이의 털 색깔에 대한 주장은 고양이 눈 색깔의 변화로 이의를 제기할 수 없습니다. 그렇다면 어떤 술어를 사용할지 어떻게 알 수 있을까요?

단순한! 우리는 단지 상태 업데이트가 어떤 술어에 종속되는지를 알려주는 요구 사항을 추가하기만 하면 됩니다. 이제 고양이의 털 색깔을 변경하는 업데이트 메시지는 "나는 이 고양이의 털 색깔을 파란색으로 만들고 분쟁은 ( )에 앉아 있는 술어가 처리할 수 있습니다. 0x123…" 일 수 있습니다.

사용자는 원하는 술어 주소를 지정할 수 있으므로 누구나 이더리움에 새 술어를 배포하여 언제든지 플라즈마 체인에 새로운 기능을 추가할 수 있습니다. 술어에는 분쟁을 처리하는 것보다 조금 더 많은 것이 있지만 나중에 살펴보겠습니다. 중요한 것은 술어가 이 다음 섹션에서 정의된 표준 인터페이스를 구현하기만 하면 된다는 것입니다.

이제 이 모든 것이 실제로 어떻게 작동하는지 자세히 살펴보겠습니다. 플라즈마 체인 설계의 빌딩 블록은 '상태 개체'입니다. 상태 객체는 두 가지 속성을 가진 데이터 조각입니다.

• predicateAddress: 개체를 제어하는 ​​온체인 주소입니다.

• parameters: 개체를 설명하는 데이터의 일부 임의 블롭입니다.

상태 개체는 사실상 자산입니다. Plasma Cash의 대체 불가능한 "코인" 개념을 일반화한 것입니다. 각각의 고유한 코인에 in Cash가 있는 것처럼 coinID각 상태 개체에는 stateID.

그게 다야! s 는 플라즈마 체인에 대한 침전물에 따라 순차적으로 할당되지만 무엇이 될 수 있는지 stateID에 대한 규칙은 없습니다 . 각 플라즈마 블록은 특정 s에서 새로운 s를 정의하는 "상태 업데이트" 모음입니다 .parameterspredicatestateObjectsstateID

범위 기반 현금 변형을 사용하기 때문에 s 는 실제로 ID stateUpdate범위에 대해 지정됩니다 .stateObject

stateUpdate = {
시작: uint,
끝: uint,
plasmaBlockNumber: uint,
stateObject: stateObject
}

운영자가 플라즈마 블록해시를 제출하는 이더리움의 플라즈마 체인 계약은 상태 업데이트가 실제로 커밋되었다는 verifyUpdate(update: stateUpdate, updateWitness:bytes[]) -> boolMerkle 포함 증명( )을 확인하는 를 구현합니다.updateWitness

술어 인터페이스

술어는 표준 계약 인터페이스를 구현해야 합니다. 해당 기능을 살펴보겠습니다.

플라즈마 계약이 하는 가장 중요한 일은 상태 업데이트의 유효성을 결정하는 것입니다. 특히, 우리는 (블록에 대한 완전한 통제권을 가진) 운영자가 자신의 유효한 상태 업데이트를 "몰래넣는" 것을 방지해야 합니다. stateObject.parameters.owner == operator이것은 도둑질이 될 것입니다!

이를 달성하기 위해 "상태 비추천"이라는 개념을 도입합니다. 주어진 것에 대한 유효한 상태는 stateID아직 "사용되지 않는" 가장 초기 업데이트의 상태라고 합니다. 상태 사용 중단은 사용되지 않은 트랜잭션 출력이 UTXO 블록체인의 사용된 트랜잭션 출력이 되는 것과 유사합니다 .

이렇게 하면 운영자가 나중에 업데이트에 몰래 들어가더라도 그녀만이 상태를 더 이상 사용하지 않을 수 있으므로 stateObject.parameters.owner == operator이전 업데이트가 우선합니다.stateObject.parameters.owner == alice

따라서 술어에서 가장 중요한 함수는 상태가 더 이상 사용되지 않을 수 있는 근거를 정의합니다.

verifyDeprecation(stateID: uint, update: stateUpdate, deprecationWitness: 바이트)

verifyDeprecation특정 true. false_ stateUpdate_ stateID_ 술어가 더 이상 사용 되지 deprecationWitness않는지 여부를 확인하는 데 사용하는 임의의 데이터입니다 . stateObject예를 들어 deprecationWitness에 의 유효한 서명을 포함하도록 요구함으로써 update.stateObject.parameters.owner소유자만 지원 중단을 승인할 수 있음을 보장합니다.

기억하세요, 이 기능은 Plasma의 종료 게임, 분쟁 등과 관련하여 실제로 더 이상 사용되지 않습니다 . 오히려 플라즈마 계약은 분쟁을 평가하기 위해 a가 더 이상 사용되지 않는지 여부를 알아야 할 때 함수를 호출합니다 .stateObject

술어 인터페이스에는 세 가지 다른 기능이 있습니다. 중요도 순으로 다음과 같습니다.

finalizeExit(종료: 바이트)

종료가 상환되면 플라즈마 계약은 클레임과 관련된 모든 자산을 조건자 주소로 보낸 다음 이 함수를 호출합니다.

canInitiateExit(stateUpdate: 바이트, initiationWitness: 바이트) -> bool

이 함수를 사용하면 조건자가 커밋된 상태에서 클레임을 시작할 수 있는 사람을 제한할 수 있습니다. 예를 들어 소유권 술어는 canInitiateExit자산 소유자로 제한하려고 할 수 있습니다.

getAdditionalDisputePeriod(stateUpdate: 바이트) -> 단위

이 기능을 사용하면 술어가 클레임의 분쟁 기간을 늘릴 수 있습니다. 우리는 더 긴 분쟁 해결 프로세스가 필요할 수 있는 복잡한 술어(예: 아토믹 스왑)에만 이것을 실제로 사용합니다. 이 함수는 일반적으로 를 반환합니다 0.

예제별 술어: 소유권 술어

예제가 있으면 모든 것이 더 쉬우므로 하나를 살펴보겠습니다. 가장 간단한 술어는 소유권 술어입니다. 이 상태는 현재 상태가 parameters.owner언제든지 종료되거나 상태 업데이트를 승인하도록 허용합니다.

술어를 만드는 첫 번째 단계는 상태 개체를 디자인하는 것입니다. 운 좋게도 그것은 매우 간단합니다. 개체 내부의 유일한 데이터는 parameters현재 소유자의 주소입니다. 소유권 조건자를 사용하는 상태 개체는 다음과 같습니다.

OwnedByAlice = { 
  매개변수: { 
    소유자: '0xAliceAddress...', 
  }, 
  술어: '0xOwnershipPredicateAddress...' 
}

구현해야 할 가장 중요한 기능은 verifyDeprecated임의의 deprecationWitness. 소유권 술어의 경우 유효는 deprecationWitness다음으로 구성됩니다.

1. 새 . state.parameters.owner_stateUpdate

2. stateUpdate새로운 것이 나중에 플라즈마 블록에서 커밋되었다는 증거 .

verifyDeprecated이러한 것들이 유효한지 확인해야 합니다. 즉, 서명과 Merkle 증명을 확인해야 합니다.

종합하면 소유자가 새 업데이트를 승인하여 소유권 상태를 더 이상 사용하지 않는 방법을 볼 수 있습니다.

나머지 기능은 매우 간단합니다. canInitiateExit청구인이 소유자인지 확인하고 finalizeExit자산을 소유자에게 전달하고 getAdditionalDisputePeriod반환할 수 있는지 확인해야 합니다 0.

코드에서 실제로 보이는 것은 다음과 같습니다! 아래에는 간단한 소유권 조건자의 Python 구현이 포함되어 있습니다. 단순함을 위해 Python으로 작성했지만 Solidity 또는 Vyper에서도 매우 쉽습니다.

보시다시피 위에서 설명한 전체 인터페이스를 구현했습니다. 그리 어렵지 않습니다 :-).

그리고 우리는 그것을 가지고 있습니다! 자산의 양도 가능한 소유권을 나타내는 술어입니다. 여기서 대부분의 논리는 플라즈마 계약에서 이미 수행된 것과 동일합니다. 우리는 심지어 ETHDenver 과정에서 변경 사항의 프로토타입을 만들었습니다 . 대부분 우리가 이미 작성한 코드를 이동하는 문제였습니다.

미래로 귀환

이 아키텍처는 플라즈마에 대한 우리의 이해에 중요한 진전입니다. 이는 결제 채널에서 일반화된 상태 채널로의 점프와 유사합니다. 플라즈마 프로토콜 자체를 업그레이드하지 않고도 플라즈마 아키텍처에 새로운 기능을 적용할 수 있습니다.

또한 우리는 술어 설계 공간이 플라즈마에 대한 풍부한 새로운 연구 영역을 제공한다고 믿습니다. 아직 초기 단계이지만 가능한 술어 중 일부는 다음과 같습니다.

• 상태 채널

• 다양한 유형의 DEX 조건자

• 조각 모음 조건 자

• 중첩 플라즈마(술어 자체가 플라즈마 계약임)

• P2P 옵션 및 CDP 계약

그러나 술어가 만병통치약이 아니라는 점을 기억하는 것이 중요합니다. 술어는 여전히 플라즈마 설계 공간 내에서 제약을 받습니다. 더 많은 일반화는 아직 발견되지 않았을 것입니다. 그럼에도 불구하고 술어는 매우 강력하며 플라즈마 캐시를 기반으로 하지 않는 것을 포함하여 거의 모든 플라즈마 구현에 유용해 보입니다.

우리는 이것이 전체 플라즈마 생태계 내에서 표준화를 위한 기회를 나타낸다고 생각합니다. 이 상태 비추천 아키텍처를 공유하는 모든 플라즈마 구현은 술어를 공유하고 새로운 방식으로 상호 운용할 수 있습니다.

Layer 2 스케일링 솔루션은 미래의 온체인 상태를 보장하기 위해 오프체인 데이터를 사용하는 것입니다. 이전 상태가 서명(상태 채널), 커밋(플라즈마) 또는 다른 어떤 것을 통해 더 이상 사용되지 않는지 여부에 관계없이 이러한 도구는 궁극적으로 동일한 작업을 수행합니다. 이러한 발전이 모든 레이어 2 솔루션을 포괄하는 통합된 공유 언어를 향한 한 걸음이 되기를 바랍니다. 우리는 지갑이 매번 맞춤형 통합을 작성하는 대신 표준 인터페이스를 활용하여 모든 레이어 2 솔루션에 연결할 수 있는 미래를 상상합니다. 상호 운용성을 위한 모든 것, 모두를 위한 상호 운용성!

자원

Python 시뮬레이션: https://github.com/plasma-group/research/tree/master/gen-plasma 기술 사양:

https://pigi.readthedocs.io/en/latest/src/specs/generalized-plasma-state .html

Plasma Contributors 텔레그램 채팅에 참여하세요: https://t.me/plasmacontributors

Alex Attar Dan Robinson Dan Tsui Georgios Konstantopoulos Jeff Coleman Mark Tyneway 매트 슬리퍼 Vitalik Buterin Xuanji Li

https://medium.com/plasma-group/plapps-and-predicates-understanding-the-generalized-plasma-architecture-fc171b25741

우리는 최근 보다 일반화된 플라즈마 아키텍처 에 대한 우리의 새로운 작업을 설명하는 기사를 게시했습니다 . 이 게시물은 내부에서 작동하는 방식에 관심이 있는 사람들을 위해 아키텍처에 대해 자세히 설명합니다. 상위 수준에서 모든 것이 어떻게 결합되는지 살펴본 다음 Python의 샘플 구현 으로 건너뛸 것입니다. 플라즈마에 대해 이미 잘 알고 있는 경우 다이어그램으로 스크롤할 수 있습니다.

이전 기사의 주요 내용은 다음과 같습니다.

1. 플라즈마 연구를 따라가는 것은 어렵습니다. 플라즈마에 익숙한 사람들은 다양한 플라즈마 맛에 대해 들어봤을 것입니다. 각 맛에는 서로 다른 장단점이 있으며 빠르게 진화하는 연구를 따라가는 것은 정규직입니다.

2. 대부분의 개발자는 dapp을 확장하는 간단하고 쉬운 방법을 원합니다. 사람들은 좋은 도구와 잘 문서화된 라이브러리를 원합니다. 그들은 확실히 단일 앱을 실행하기 위해 처음부터 전체 블록체인을 구축하기를 원하지 않습니다.

그래서 우리는 플라즈마 전문가가 아니어도 확장 가능한 블록체인 애플리케이션을 쉽게 구축할 수 있는 플랫폼을 만들기 시작했습니다. 우리는 앱(또는 "플랩")을 구축할 수 있는 범용 플라즈마 체인으로 끝났습니다. 아직 이상하게 들리나요? 플랩. Plaaapp. 플랩. 예.

"레이어 2"의 핵심 아이디어는 메인 블록체인 외부의 데이터("오프체인 데이터")를 사용하여 메인 블록체인에 있는 자산("온체인 데이터")에 대한 보증을 제공할 수 있다는 것입니다. 예를 들어, 해당 오프체인 데이터는 이더리움의 온체인 에스크로 계약에 보관된 자산을 인출할 수 있는 권리를 부여할 수 있습니다. 그러나 그 자산의 소유권은 이더리움을 건드리지 않고 손이 바뀌었습니다.

물론 오프체인 데이터는 결국 메인 블록체인에서 어떤 일이 일어날 가능성이 없다면 유용하지 않습니다. 이것은 일반적으로 사용자가 오프체인 데이터에 대한 "클레임"을 청구되는 자산이 보관된 온체인 스마트 계약에 제출하도록 허용함으로써 달성됩니다. 이 주장은 "자산 X를 인출할 수 있다는 서명된 메시지가 있습니다."와 같은 것일 수 있습니다.

그러나 클레임을 제출한 후 앞서 언급한 클레임을 한 사람이 다른 사람 에게 자산 X를 보내는 메시지를 노래하면 어떻게 됩니까 ? 이것은 위의 철회를 무효화합니다. 이러한 유효하지 않은 철회가 실패하지 않도록 모든 청구에 분쟁 기간을 추가합니다. 누구나 분쟁 기간이 끝나기 전에 청구에 이의를 제기할 수 있습니다. 그렇지 않으면 청구가 유효한 것으로 간주됩니다. 충분히 간단합니다!

이것을 다시 플라즈마와 빠르게 연관시키겠습니다. 플라즈마 체인은 일련의 블록으로 구성되며 각 블록은 일련의 트랜잭션으로 구성됩니다. 새로운 플라즈마 체인 블록이 생성될 때마다 해당 블록에 대한 암호화 커밋이 메인 체인에 게시됩니다. 이러한 커밋은 해당 블록 내부에 무언가가 있음을 증명하는 데 사용할 수 있습니다. 우리의 경우 이 커밋은 블록의 모든 상태 업데이트에서 생성된 머클 루트입니다.

이더리움의 플라즈마 스마트 계약은 운영자가 플라즈마 블록을 커밋한 순서를 기록하고 커밋을 덮어쓰는 것을 방지합니다.따라서 이러한 블록 커밋은 우리에게 시간 감각을 제공합니다. 사용자가 플라즈마 체인에서 발생한 일에 대해 주장을 하고 싶을 때 블록 번호를 통해 해당 일이 발생한 시기 도 참조해야 합니다 . 예를 들어, 사용자는 "여기 에 자산 Z를 제공한 블록 Y의 트랜잭션 X가 있습니다."라고 말할 수 있습니다. 이 추가 시간 차원은 분쟁에 있어서도 중요합니다. 어떤 일이 다른 일 이전에 일어났는지 이후에 일어났는지 알고 싶을 때가 있기 때문입니다!

추상적인 오프체인 데이터주의

방금 본 것처럼 레이어 2는 주로 일부 오프체인 데이터를 사용하여 온체인에 있는 것에 영향을 주는 것입니다. 지금까지 오프체인 데이터는 소유권을 나타내는 데 주로 사용되었습니다 . 누가 무엇을 소유하고 있는지, 소유권이 바뀌었는지 여부입니다.

Alice는 Ethereum의 스마트 계약에 자산을 예치하고 해당 자산의 소유자가 됩니다. 그런 다음 그녀는 자산 소유권을 Bob에게 이전하는 오프체인 메시지에 서명할 수 있습니다. 그런 다음 Bob은 서명된 메시지를 사용하여 청구함으로써 Ethereum에서 자산을 다시 인출할 수 있습니다.

우리는 또한 소유권보다 더 복잡한 것을 나타낼 수 있습니다. 앨리스가 크립토키티를 입금하고 키티의 털 색깔을 바꾸는 여러 메시지에 서명했다고 가정해 봅시다. 위의 예에서와 같이 그녀는 결국 그녀가 서명한 마지막 메시지를 사용하여 새끼 고양이의 털 색깔에 대해 이더리움에서 주장할 수 있습니다!

새끼 고양이의 털 색깔이나 눈 색깔이 바뀌든 이더리움의 스마트 계약은 이러한 변화를 이해할 수 있는 방법이 필요합니다. 각각의 새로운 기능 또는 새로운 유형의 "상태 전환"에는 플라즈마 계약이 뒤따르는 논리의 변경이 필요합니다. 이전 플라즈마 사양에서 이와 같은 기능을 추가하면 *전체* 플라즈마 계약을 재배포하고 모든 사람의 자산을 이전 플라즈마 체인에서 새 것으로 마이그레이션해야 함을 의미했습니다. 이는 안전하거나 확장 가능하거나 업그레이드할 수 없습니다.

우리는 새로운 기능을 추가하고자 하는 플라즈마 체인 설계에 충분히 도달한 후 이 업그레이드 가능성 문제에 부딪쳤습니다. 약간의 브레인스토밍 후에 우리는 주요 플라즈마 체인 계약을 변경하지 않고 새로운 기능을 추가하는 쉬운 방법이 있다는 것을 깨달았습니다.

지금까지 이야기한 다양한 시나리오에는 공통점이 있습니다. 오프체인 데이터는 항상 잘못된 온체인 주장을 "논쟁"하기 위한 것입니다. 특정 클레임에 대한 분쟁은 기본적으로 클레임에 언급된 상태가 구식이라는 증거일 뿐입니다. 소유권 분쟁은 소유권 주장을 한 사용자가 나중에 다른 사람에게 소유권을 이전했음을 증명합니다. 고양이 털 색상에 대한 분쟁은 고양이 털 색상이 변경되었음을 증명해야 합니다.

우리의 주요 돌파구는 분쟁 조건이 기본 스마트 계약에서 확인할 필요가 없다는 것을 깨닫는 것이었습니다. 대신, 분쟁이 유효한지 여부를 알려주는 기능을 구현하는 다른 스마트 계약을 가질 수 있습니다. 해당 기능에 필요한 논리를 구현한 새 계약을 생성하여 새 기능을 추가한 다음 기본 계약이 새 계약을 참조하도록 할 수 있습니다. 이러한 외부 계약을 '술어' 라고 합니다 .

이제 새 기능을 추가하는 것은 정말 쉬웠지만 여전히 특정 상태 업데이트에 사용할 술어를 알 수 있는 방법이 필요했습니다. 새끼 고양이의 털 색깔에 대한 주장은 고양이 눈 색깔의 변화로 이의를 제기할 수 없습니다. 그렇다면 어떤 술어를 사용할지 어떻게 알 수 있을까요?

단순한! 우리는 단지 상태 업데이트가 어떤 술어에 종속되는지를 알려주는 요구 사항을 추가하기만 하면 됩니다. 이제 고양이의 털 색깔을 변경하는 업데이트 메시지는 "나는 이 고양이의 털 색깔을 파란색으로 만들고 분쟁은 ( )에 앉아 있는 술어가 처리할 수 있습니다. 0x123…" 일 수 있습니다.

사용자는 원하는 술어 주소를 지정할 수 있으므로 누구나 이더리움에 새 술어를 배포하여 언제든지 플라즈마 체인에 새로운 기능을 추가할 수 있습니다. 술어에는 분쟁을 처리하는 것보다 조금 더 많은 것이 있지만 나중에 살펴보겠습니다. 중요한 것은 술어가 이 다음 섹션에서 정의된 표준 인터페이스를 구현하기만 하면 된다는 것입니다.

이제 이 모든 것이 실제로 어떻게 작동하는지 자세히 살펴보겠습니다. 플라즈마 체인 설계의 빌딩 블록은 '상태 개체'입니다. 상태 객체는 두 가지 속성을 가진 데이터 조각입니다.

• predicateAddress: 개체를 제어하는 ​​온체인 주소입니다.

• parameters: 개체를 설명하는 데이터의 일부 임의 블롭입니다.

상태 개체는 사실상 자산입니다. Plasma Cash의 대체 불가능한 "코인" 개념을 일반화한 것입니다. 각각의 고유한 코인에 in Cash가 있는 것처럼 coinID각 상태 개체에는 stateID.

그게 다야! s 는 플라즈마 체인에 대한 침전물에 따라 순차적으로 할당되지만 무엇이 될 수 있는지 stateID에 대한 규칙은 없습니다 . 각 플라즈마 블록은 특정 s에서 새로운 s를 정의하는 "상태 업데이트" 모음입니다 .parameterspredicatestateObjectsstateID

범위 기반 현금 변형을 사용하기 때문에 s 는 실제로 ID stateUpdate범위에 대해 지정됩니다 .stateObject

stateUpdate = {
시작: uint,
끝: uint,
plasmaBlockNumber: uint,
stateObject: stateObject
}

운영자가 플라즈마 블록해시를 제출하는 이더리움의 플라즈마 체인 계약은 상태 업데이트가 실제로 커밋되었다는 verifyUpdate(update: stateUpdate, updateWitness:bytes[]) -> boolMerkle 포함 증명( )을 확인하는 를 구현합니다.updateWitness

술어 인터페이스

술어는 표준 계약 인터페이스를 구현해야 합니다. 해당 기능을 살펴보겠습니다.

플라즈마 계약이 하는 가장 중요한 일은 상태 업데이트의 유효성을 결정하는 것입니다. 특히, 우리는 (블록에 대한 완전한 통제권을 가진) 운영자가 자신의 유효한 상태 업데이트를 "몰래넣는" 것을 방지해야 합니다. stateObject.parameters.owner == operator이것은 도둑질이 될 것입니다!

이를 달성하기 위해 "상태 비추천"이라는 개념을 도입합니다. 주어진 것에 대한 유효한 상태는 stateID아직 "사용되지 않는" 가장 초기 업데이트의 상태라고 합니다. 상태 사용 중단은 사용되지 않은 트랜잭션 출력이 UTXO 블록체인의 사용된 트랜잭션 출력이 되는 것과 유사합니다 .

이렇게 하면 운영자가 나중에 업데이트에 몰래 들어가더라도 그녀만이 상태를 더 이상 사용하지 않을 수 있으므로 stateObject.parameters.owner == operator이전 업데이트가 우선합니다.stateObject.parameters.owner == alice

따라서 술어에서 가장 중요한 함수는 상태가 더 이상 사용되지 않을 수 있는 근거를 정의합니다.

verifyDeprecation(stateID: uint, update: stateUpdate, deprecationWitness: 바이트)

verifyDeprecation특정 true. false_ stateUpdate_ stateID_ 술어가 더 이상 사용 되지 deprecationWitness않는지 여부를 확인하는 데 사용하는 임의의 데이터입니다 . stateObject예를 들어 deprecationWitness에 의 유효한 서명을 포함하도록 요구함으로써 update.stateObject.parameters.owner소유자만 지원 중단을 승인할 수 있음을 보장합니다.

기억하세요, 이 기능은 Plasma의 종료 게임, 분쟁 등과 관련하여 실제로 더 이상 사용되지 않습니다 . 오히려 플라즈마 계약은 분쟁을 평가하기 위해 a가 더 이상 사용되지 않는지 여부를 알아야 할 때 함수를 호출합니다 .stateObject

술어 인터페이스에는 세 가지 다른 기능이 있습니다. 중요도 순으로 다음과 같습니다.

finalizeExit(종료: 바이트)

종료가 상환되면 플라즈마 계약은 클레임과 관련된 모든 자산을 조건자 주소로 보낸 다음 이 함수를 호출합니다.

canInitiateExit(stateUpdate: 바이트, initiationWitness: 바이트) -> bool

이 함수를 사용하면 조건자가 커밋된 상태에서 클레임을 시작할 수 있는 사람을 제한할 수 있습니다. 예를 들어 소유권 술어는 canInitiateExit자산 소유자로 제한하려고 할 수 있습니다.

getAdditionalDisputePeriod(stateUpdate: 바이트) -> 단위

이 기능을 사용하면 술어가 클레임의 분쟁 기간을 늘릴 수 있습니다. 우리는 더 긴 분쟁 해결 프로세스가 필요할 수 있는 복잡한 술어(예: 아토믹 스왑)에만 이것을 실제로 사용합니다. 이 함수는 일반적으로 를 반환합니다 0.

예제별 술어: 소유권 술어

예제가 있으면 모든 것이 더 쉬우므로 하나를 살펴보겠습니다. 가장 간단한 술어는 소유권 술어입니다. 이 상태는 현재 상태가 parameters.owner언제든지 종료되거나 상태 업데이트를 승인하도록 허용합니다.

술어를 만드는 첫 번째 단계는 상태 개체를 디자인하는 것입니다. 운 좋게도 그것은 매우 간단합니다. 개체 내부의 유일한 데이터는 parameters현재 소유자의 주소입니다. 소유권 조건자를 사용하는 상태 개체는 다음과 같습니다.

OwnedByAlice = { 
  매개변수: { 
    소유자: '0xAliceAddress...', 
  }, 
  술어: '0xOwnershipPredicateAddress...' 
}

구현해야 할 가장 중요한 기능은 verifyDeprecated임의의 deprecationWitness. 소유권 술어의 경우 유효는 deprecationWitness다음으로 구성됩니다.

1. 새 . state.parameters.owner_stateUpdate

2. stateUpdate새로운 것이 나중에 플라즈마 블록에서 커밋되었다는 증거 .

verifyDeprecated이러한 것들이 유효한지 확인해야 합니다. 즉, 서명과 Merkle 증명을 확인해야 합니다.

종합하면 소유자가 새 업데이트를 승인하여 소유권 상태를 더 이상 사용하지 않는 방법을 볼 수 있습니다.

나머지 기능은 매우 간단합니다. canInitiateExit청구인이 소유자인지 확인하고 finalizeExit자산을 소유자에게 전달하고 getAdditionalDisputePeriod반환할 수 있는지 확인해야 합니다 0.

코드에서 실제로 보이는 것은 다음과 같습니다! 아래에는 간단한 소유권 조건자의 Python 구현이 포함되어 있습니다. 단순함을 위해 Python으로 작성했지만 Solidity 또는 Vyper에서도 매우 쉽습니다.

보시다시피 위에서 설명한 전체 인터페이스를 구현했습니다. 그리 어렵지 않습니다 :-).

그리고 우리는 그것을 가지고 있습니다! 자산의 양도 가능한 소유권을 나타내는 술어입니다. 여기서 대부분의 논리는 플라즈마 계약에서 이미 수행된 것과 동일합니다. 우리는 심지어 ETHDenver 과정에서 변경 사항의 프로토타입을 만들었습니다 . 대부분 우리가 이미 작성한 코드를 이동하는 문제였습니다.

미래로 귀환

이 아키텍처는 플라즈마에 대한 우리의 이해에 중요한 진전입니다. 이는 결제 채널에서 일반화된 상태 채널로의 점프와 유사합니다. 플라즈마 프로토콜 자체를 업그레이드하지 않고도 플라즈마 아키텍처에 새로운 기능을 적용할 수 있습니다.

또한 우리는 술어 설계 공간이 플라즈마에 대한 풍부한 새로운 연구 영역을 제공한다고 믿습니다. 아직 초기 단계이지만 가능한 술어 중 일부는 다음과 같습니다.

• 상태 채널

• 다양한 유형의 DEX 조건자

• 조각 모음 조건 자

• 중첩 플라즈마(술어 자체가 플라즈마 계약임)

• P2P 옵션 및 CDP 계약

그러나 술어가 만병통치약이 아니라는 점을 기억하는 것이 중요합니다. 술어는 여전히 플라즈마 설계 공간 내에서 제약을 받습니다. 더 많은 일반화는 아직 발견되지 않았을 것입니다. 그럼에도 불구하고 술어는 매우 강력하며 플라즈마 캐시를 기반으로 하지 않는 것을 포함하여 거의 모든 플라즈마 구현에 유용해 보입니다.

우리는 이것이 전체 플라즈마 생태계 내에서 표준화를 위한 기회를 나타낸다고 생각합니다. 이 상태 비추천 아키텍처를 공유하는 모든 플라즈마 구현은 술어를 공유하고 새로운 방식으로 상호 운용할 수 있습니다.

Layer 2 스케일링 솔루션은 미래의 온체인 상태를 보장하기 위해 오프체인 데이터를 사용하는 것입니다. 이전 상태가 서명(상태 채널), 커밋(플라즈마) 또는 다른 어떤 것을 통해 더 이상 사용되지 않는지 여부에 관계없이 이러한 도구는 궁극적으로 동일한 작업을 수행합니다. 이러한 발전이 모든 레이어 2 솔루션을 포괄하는 통합된 공유 언어를 향한 한 걸음이 되기를 바랍니다. 우리는 지갑이 매번 맞춤형 통합을 작성하는 대신 표준 인터페이스를 활용하여 모든 레이어 2 솔루션에 연결할 수 있는 미래를 상상합니다. 상호 운용성을 위한 모든 것, 모두를 위한 상호 운용성!

자원

Python 시뮬레이션: https://github.com/plasma-group/research/tree/master/gen-plasma 기술 사양:

https://pigi.readthedocs.io/en/latest/src/specs/generalized-plasma-state .html

Plasma Contributors 텔레그램 채팅에 참여하세요: https://t.me/plasmacontributors

Alex Attar Dan Robinson Dan Tsui Georgios Konstantopoulos Jeff Coleman Mark Tyneway 매트 슬리퍼 Vitalik Buterin Xuanji Li

https://medium.com/plasma-group/plapps-and-predicates-understanding-the-generalized-plasma-architecture-fc171b25741