구조
거버넌스는 PoA(Operator 한명이 운영)라 가정함
*이해를 돕기 위해 개인적으로 구성한 이미지 입니다.
- Client: User와 Operator, 플라즈마 체인상의 참여자(노드), 이더리움 geth와 유사함.
- Core: 플라즈마 체인에서 클라이언트 간 거래가 이루어지는 영역,
- 블록체인 core의 기능과 유사함
*실제 코드와 다릅니다.
- plasma contract(on ethereum): 루트체인(이더리움)에 거래의 요약된 정보를 기록하기 위해서 배포된 스마트 컨트랙트
- deposit, submit(commit) function
참여자의 역할
트랜잭션에서 *PETH value만 교환한다고 가정
*PETH: Plasma chai ETH
User
- 자신과 관련된 트랜잭션만을 포함하는 블록을 생성하며, 각자의 체인을 가진다. (Nano-like DAG)
- 자신과 관련된 트랜잭션이 최종적으로 루트 체인 상에 제대로 기록되는지 감시한다.
- 관찰비용 절감: 기존 플라즈마 체인의 참여자들은 Operator가 체인을 제대로 운영하고 검증하는지 체인의 모든 트랜잭션과 블록을 지켜보고 있어야하지만, PlasmaDAG의 User들은 본인의 트랜잭션을 제대로 처리하는지만 감시한다.
- 대체로 블록과 트랜잭션이 1대1 대응하지만 다수에게 value를 전송하는 경우 여러 트랜잭션을 블록에 담을 수 있다.
- attack 발생시, Mal-acting당사자만 제거된다.
Operator
- global state 관리: 모든 참여자들이 생성하는 블록을 검증(Validate)하고 검증된 블록을 자신의 체인에 연결한다.
- checkpoint를 통한 Finality보장: 주기적으로 부모체인(이더리움 등의 루트체인)에 aggregate된 TX요약과 모든User들의 total balance를 전송한다(commit)
- aggregate방법: 두개의 트랜잭션을 해시하는 방식으로 Merkle root가 루트체인에 담기게 된다.
- Operator는 송금을 위한 트랜잭션을 발행하지는 않는다.
초기화와 User 참여
- Operator가 루트체인의 스마트컨트랙트에 deposit을 예치하고 사이드 체인을 초기화한다.
- User는 Smart contract에 deposit을 예치하고, 본인의 제네시스 블록을 생성후, operator에게 승인을 요청한다.
- User들의 deposit 총량(totalSupply_)은 operator의 deposit을 넘을수 없다.
- Operator의 watcher가 컨트랙트 발생을 관찰하고 있다가 Deposit event 로그를 확인하여 플라즈마 체인에 반영한다.
트랜잭션 발행
- 송금을 원하는 User(sender)는 receiver의 address와 value 정보를 담은 트랜잭션을 발행하고 이를 담은 블록을 생성하여 receiver에게 전달한다.
- receiver는 받은 트랜잭션과 함께 이전에 발행된 트랜잭션을 포함하는 블록을 생성하여 다른 사용자들에게 알린다.
트랜잭션 승인 (주기적 submit, commit)
- Operator는 User들이 생성한 블록을 검증하고 해당 블록이 올바른 경우 자신의 체인에 연결한다. (1차 승인, sumitBlock)
- User들은 자신의 블록이 Operator의 체인에 연결되었는지 확인후 이를 승인한다. (2차 승인)
- 승인 방법은 User가 새로운 트랜잭션을 발행하면 이를 승인한것으로 간주한다.
- Operator가 검증을 올바르게 하지 못해 User가 손해를 봤을 경우, 해당 손해를 operator의 deposit에서 제외하기 때문에 성실하게 검증할 유인이 된다.
sender와 receiver가 관련된 동일한 트랜잭션이 포함된 블록이더라도 블록해시는 다를수 밖에 없으나 sender와 receiver가 생성하는 블록마다 Operator에 연결하게되면 Operator는 동일한 트랜잭션이 담긴 블록을 2개씩 갖게된다.
exit(withdrawal)
공격 대응
References