먼저 읽고오기:
http://www.seunghwanhan.com/2015/06/ethereum-introduction_3.html
------
암호화폐의 장부는 상태변환시스템:
------
1) 모든 코인의 소유권현황의 '상태(state)'
2) 현상태와 트랜잭션을 받아서 그 결과로 새로운 상태를 출력해주는 '상태변환함수(state transition function)'
이러한 상태변환를 비트코인 장부에서는 다음과 같이 정의할 수 있다.
APPLY(S,TX) -> S' or ERROR
1. TX의 각 입력에 대해 :
1.1 만약 참조된 UTXO가 S에 없다면, 에러를 리턴.
1.2 만약 서명이 UTXO의 소유자와 매치되지 않으면, 에러를 리턴.
2. 만약 입력에 사용된 UTXO들 금액의 합이 출력 UTXO들 금액의 합보다 작으면, 에러를 리턴.
3. 입력에 사용된 UTXO가 삭제되고 출력 UTXO가 추가된 S를 리턴.
여기서 1번의 첫번째 과정은 존재하지 않는 코인이 트랜잭션에 사용되는 것을 막기 위한 것이고
1번의 두번째 과정은 다른 사람의 코인이 트랜잭션에 사용되는 것을 막기 위한 것이다.
* UTXO(Unspent Transaction Outputs): 아직 사용되지 않은 모든 코인들의 집합
e.g. (이걸 이해해야함)
Alice가 Bob에게 11.7 BTC를 보내고 싶다고 가정하자. 먼저 Alice 지갑주소로부터 표시된 금액의 합이 적어도 11.7 BTC 이상인 UTXO의 집합을 찾는다. 실제 대부분의 경우에는 11.7 BTC를 정확히 바로 선택할 수 없다. Alice의 지갑주소에서 각각 6, 4, 2 BTC 가 표시된 3개의 UTXO를 참조할 수 있다고 하자. 이 3개의 UTXO가 트랜잭션의 input이 되고 2개의 output이 생성된다. Output 중 하나는 11.7 BTC가 표시된 새로운 UTXO이며 소유자는 Bob의 지갑주소가 된다. 그리고 다른 하나는 12(6+4+2) - 11.7 = 0.3 BTC의 "잔돈(change)"이 표시된 새로운 UTXO이며 소유자는 Alice 자신의 지갑주소가 된다.
------
블록체인 채굴: Decentralised Exchange
------
1. 이 블록에 의해 참조되는 이전 블록이 존재하는지, 유효한지 확인한다.
2. 타임스탬프 값이 이전 블록의 타임스탬프 값보다 크면서 2시간 이내인지 확인한다.
3. 작업증명(proof of work)이 유효한지 확인한다.
4. S[0]를 이전 블록의 마지막 상태(state)가 되도록 설정한다.
5. TX를 n개의 트랜잭션을 가지는, 블록의 트랜잭션 목록으로 가정한다. 폐구간 0...n-1의 모든 i에 대해, S[i+1] = APPLY(S[i], TX[i])집합 중 어느 하나라도 에러를 리턴하면 거짓(false)을 리턴하며 종료한다.
6. 참(true)을 리턴하고, S[n]를 이 블록의 마지막 상태로 등록한다.
------
머클트리(Merkle tree)
------
이진트리의 일종. 머클트리의 목적은 어떤 블록의 데이터가 분리돼서 전달될 수 있도록 하는 것
full node뿐 아니라 light node에서도 branch의 유효성을 입증가능하게 한다.
머클트리에서 하위 노드들의 해시값이 상위 노드에 영향을 주기 때문에 어떤 악의적인 유저가 머클트리 최하위에 있는 트랜잭션 정보를 가짜로 바꿔치기 하면 상위 부모들의 해시값들이 변해서 결국 트리의 루트값이 바뀌므로, 결과적으로 이 블록의 해시가 달라지기 때문이다. 이렇게 되면 이 블록은 완전히 다른 블록으로 인식되게 되며, 이것은 유효하지 않은 작업증명을 가지고 있게 될 것이 분명하다.
머클트리 프로토콜은 비트코인 네트워크를 장기간 지속가능하게 만드는 기초가 된다. 비트코인 네트워크에서 각 블록의 모든 정보를 저장하고 처리하는 "완전노드(full node)"는 2014년 4월 기준으로 거의 15 GB의 디스크 공간을 필요로 하며 매달 1 GB 넘게 증가하고 있다. 현재 데스크탑 컴퓨터 정도에서는 수용할 수 있지만 스마트폰에서는 불가능하다. 그리고 나중에는 소수의 사업체들이나 풀 노드를 유지할 수 있을 것이다. 반면 "단순화된 지불검증(simplified payment verification, SPV)"으로 알려진 프로토콜은 "가벼운 노드(light node)"라고 불리는 또 다른 형태의 노드를 가능하게 해준다. 가벼운 노드는 블록헤더를 다운로드하고 그 블록헤더에서 작업증명을 검증한다. 그리고 관련 트랜잭션들에 대한 "곁가지들(branches)"만을 다운로드 한다. 이렇게 전체 블록체인의 매우 작은 비율만을 다운로드 함에도 불구하고 강한 안전성을 보장하면서도, 임의의 트랜잭션의 상태 및 잔고 상태를 알아낼 수 있게 한다.
-> 풀노드는 계속 커지니까 몇몇 기업만 유지가능하게 될 것이다.
-> 하지만 라이트노드 또한 SPV 프로토콜을 이용하기 때문에 매우 작은 비율만 다운로드해도 기존의 안전성이 보장된다.
---
블록체인의 확장
---
여러 방향으로 확장되려는 시도가 있었다.
네임코인: '탈중앙화된 명칭 등록 데이터베이스' 계정 등록과 관련. 먼저 등록한 사람이 성공하고 두 번째 등록한 사람은 실패하도록 하는 시스템. 이는 이미 비트코인 합의 규약에 완벽히 적용.
컬러드 코인: 누구나 비트코인 블록체인 위에서 자신만의 고유한 디지털 화폐를 발행할 수 있는 프로토콜 역할 수행 가능. 또는 자기 자신만의 디지털 토큰을 발행하려 하는 프로토콜 역할수행 또한 가능. 이 프로토콜은 블록체인을 처음부터 끝까지 역추적해 그들이받은 UTXO의 색깔을 정함으로써, 사용자가 특정 색깔을 가진 UTXO만 지갑에 간직하고 그 코인을 보통 비트코인처럼 여기저기 보낼 수 있게 한다.
메타코인: 비트코인 거래를 메타코인 거래 저장에 이용하되, 상태 이동 함수 APPLY' 를 다르게 가짐으로써, 비트코인 시스템 위에서 운영되는 프로토콜을 갖는 것. 메타코인 프로토콜만으로는 비트코인 블록체인 속에 무효 메타코인 거래가 나타나는 현상을 예방 수 없기 때문에, 규칙이 하나 더해진다. 즉 만약 APPLY'(S, TX)가 에러를 리턴하면, 프로토콜은 APPLY'(S,TX)=S로 정해진다. 비트코인 스스로는 내부 실행이 불가능한, 잠재적으로 더 발전된 성질을 가진 무작위 암호화폐 프로토콜을 만드는 쉬운 메커니즘
consensus protocol(합의 프로토콜) 만들려는데는 두가지 방법이 있다. 또한 각각의 특징을 기술한다.
1. 독립적인 네트워크를 세우는 것
-> 각 개별 실행주체가 모든 필요한 상태변환과 네트워킹 코드를 건설하고 점검해야 할 뿐만 아니라 독립적인 블록체인을 구동시켜야 한다. 나아가, 분권 합의 기술에 관한 어플리케이션의 집합이 멱함수분포를 따를 것으로 예상된다. 즉, 대다수 어플리케이션은 자기 자신의 블록체인을 보장하기에는 너무 작을 것이다. 그리고 또 거대한 클래스의 분권화된 어플리케이션, 즉 서로 교류를 하기 위한 분권화된 자율 기구(DAO)가 생겨날 것이라고 예상한다.
2. 비트코인 시스템 대로 가는 것
-> 비트코인의 단순 지불 검증(SPV)특징을 물려받지 못한다는 단점이 있다. 단순지불검증은 비트코인에서는 작동한다. 왜냐하면 비트코인은 블록체인 깊이(depth)를 검증 대리 수단으로 이용할 수 있기 때문이다. 한 거래의 근원을 찾아 충분히 뒤로 돌아가보면, 그 상태의 정합성을 증명하는 부분이 있었다고 말해도 무방하다. 반면, 블록체인에 기반한 메타-프로토콜은 무효거래가 블록체인에 포함되지 않도록 막을 방법이 자기 자신의 프로토콜 자체에는 없다. 그렇기 때문에 완전히 안전보장이 된 단순지불검증 메타-프로토콜이라면, 어떤 거래가 유효한지 아닌지를 결정하기위해, 항상 비트코인 블록체인의 원점까지 돌아가 훑어보는 작업이 필요하다. 현재까지 비트코인에 기반한 메타-프로토콜의 모든 "간단한"(light) 클라이언트 구현은 자료를 제공하는 믿을 만한 서버에 의지하고 있는 형편이다. 우리가 암호화폐를 만든 가장 중요한 목적이 제3의 신용기구의 필요성을 없애는 것이었다는 걸 특히 되새겨본다면, 이것은 아주 분명하게도, 차선의 결과가 될 뿐이다.
------
스크립팅
------
비트코인 프로토콜도 smart contract(스마트 컨트랙트)가 제한적으로 가능하다.
주요 한계점
1. 튜링불완전성
2. 가치무지(Value-blindness): UTXO 스크립트만으로는 인출 액수를 세밀하게 통제할 방법이 없다.
3. 다양한 상태 표현이 불가(Lack of State): 이 점이 분산 환전 거래나 이중 암호 실행 프로토콜(계산 보상금을 보장하기 위해 필요하다)과 같은 다중 조건 계약을 어렵게 한다. 즉 UTXO은 단순하고 1회적인 계약에만 이용될 수 있을 뿐, 분산조직과 같은 더 복잡한 "상태적(stateful)" 계약에는 이용될 수 없고 메타프로토콜을 적용하기 어렵게 만든다.
4. 블록체인 해독 불가(Blockchain-blindness): 논스(Nonce), 타임스탬프,이전 블록해시같은 블록체인 자료를 해독하지 못한다.
발전된 어플리케이션을 만드는 데 3가지 접근법이 있다.
1. 독립적인 블록체인을 만드는 것
-> 무한히 자유로운 프로그램을 짤 수 있지만 개발 기간, 초기 셋업 작업, 보안 등의 비용을 치뤄야 한다.
2. 비트코인에 이미 내재된 스크립트를 이용하는 것
-> 비트코인에 내재된 스크립트를 이용하면 실행이 간단하고 표준화된다는 장점이 있지만, 이용범위가 제한적이다.
3. 비트코인 상에서 작동되는 메타-규약을 건설하는 것
-> 메타규약을 쓰는 것은 간단하긴 하지만, 확장성의 결함을 감수해야 한다.
그래서 이더리움을 만들려한다. -> 대안 프레임워크(alternative framework)를 건설
------
Ethereum
------
분산 어플리케이션 제작을 위한 대체 프로토콜을 만드는 것. 대규모 분산 어플리케이션에 유용할 것이라 생각되는 다른 종류의 제작기법을 제공하며, 빠른 개발 시간, 작고 드물게 사용되는 어플리케이션을 위한 보안, 다른 어플리케이션과의 효율적인 상호작용이 중요한 상황에 특히 주안점을 두고 있다.
이더리움은 앞서 말한 비트코인 프로토콜의 단점을 모두 상쇄시켰다.
* 스마트 컨트랙트
* DApp 구현
* 소유권 규칙, 트랜잭션 형식, 상태변환 함수 생성 가능
몇줄 안되는 짧은 코드로 아래 요소에 대한 간단한 구현도 가능하다.
-> 네임코인
-> 스마트 컨트랙트
-> 통화(currency), 평판(reputation)시스템
------
Ethereum Accounts
------
이더리움의 상태: 어카운트(account)라고 하는 오브젝트(object)들로 구성되어있다.
20바이트의 주소, 어카운트간 상태 변환
이더리움 어카운트:
논스(nonce): 트랜잭션이 오직 한번만 처리되게 하는 카운터
이더(ether)* 잔고
계약 코드(if present)
저장 공간(empty by default)
* 이더(ether): 내부 암호연료(crypto-fuel), 트랜잭션 수수료 지불용.
어카운트의 종류:
외부 소유 어카운트(Externally Owned Accounts): 프라이빗 키에 의해 통제. 아무런 코드도 가지고 있지 않으며, 이 어카운트에서 메시지를 보내기 위해서는 새로운 트랜잭션을 하나 만들고, 서명(signing)을 해야 한다.
컨트랙트 어카운트(Contract Accounts): 컨트랙트 코드에 의해 통제. 메시지를 받을 때마다, 자신의 코드를 활성화시키고, 이에 따라 메시지를 읽거나 내부 저장공간에 기록하고, 다른 메시지들을 보내거나, 컨트랙트들을 차례로 생성하게 된다.
컨트랙트(contract)?: 수행되거나 컴파일 되어져야 할 어떤 것이라기 보다는, 이더리움의 실행 환경안에 살아있는 일종의 자율 에이전트(autonomous agents)로서, 메시지나 트랜잭션이 도착하면 항상 특정한 코드를 실행하고, 자신의 이더 잔고와, 영속적인 변수들을 추적하기 위해 자신의 키/값 저장소를 직접적으로 통제하는 역할을 한다.
------
메시지와 트랜잭션
------
1. 이더리움에서의 트랜잭션은 다음 값들을 포함한다:
메시지 수신처[x]
발신처를 확인할 수 있는 서명[x]
발신처가 수신처로 보내는 이더의 양[x]
선택적(optional) 데이터 필드
STARTGAS 값, 트랜잭션 실행이 수행되도록 허용된 최대 계산 단계수
GASPRICE 값, 매 계산단계마다 발신처가 지불하는 수수료
위의 세가지는 암호화폐에서는 필수.
데이터필드: 초기값은 아무기능을 하지않음. 가상환경에서는 opcode를 가지고 있다. 블록체인 위에 도메인 등록 서비스로 기능하고 있는 컨트랙트가 있을 경우, 이 컨트랙트로 보내지는 데이터는 두개의 필드를 가지고 있는 것으로 해석할 수 있다. 첫번째 필드는 등록하고자 하는 도메인이고, 두번째 필드는 IP 주소이다. 컨트랙트는 메시지 데이터로부터 이 값들을 읽어서 저장소 내 적당한 위치에 저장한다.
STARTGAS, GASPRICE: 이더리움의 anti-DoS방지책. 무한루프 , 계산 낭비를 막음. 계산 단위는 gas. 계산에 1gas를 씀. 바이트당 5 gas의 수수료를 지불. 소비하는 모든 리소스에 대한 수수료 지불 필요.
2. 이더리움에서 사용되는 메시지는 다음을 의미한다. 임의의 컨트랙트가 다른 컨트랙트에 "메시지" 를 전달하는 것. 이더리움 실행환경에서만 존재하는 가상의 오브젝트이다. 메시지는 아래의 값들을 포함한다:
(암묵적으로) 메시지 발신처
메시지 수신처
메시지와 함께 전달되는 이더
선택적 데이터 필드
STARTGAS 값
메시지는 컨트랙트에 의해 생성됨. 코드 수행을 하고 있는 컨트랙트가 메시지를 생성하고 실행하라는 CALL opcode를 만나게 되면 메시지를 생성함.
트랜잭션이나 컨트랙트에 의해 할당된 gas 허용치는 그 트랜잭션과 모든 하위 실행에 의해 소모된 총 gas 에 적용된다. 예를 들어, 외부 실행자 A가 B에게 1000 gas와 함께 트랜잭션을 보내고, B는 600 gas를 소모한 뒤 C에게 메시지를 보내고, C의 내부 실행에 300 gas를 소모한 후 반환하면, B는 gas가 모두 소모되기 전에 100 gas를 더 사용할 수 있다. (??)
------
이더리움 상태 변환 함수(Ethereum State Transition Function)
------
이더리움 상태 전이 함수 APPLY(S, TX) -> S’ 는 다음처럼 정의될 수 있다.
1. 트랜잭션 형태 점검
2. 트랜잭션 수수료 계산 후 발신자 논스 증가.
2.1 수수료가 없다면 오류.
3. GAS = STARTGAS로 계산. 바이트당 gas의 특정양 차감. 트랜잭션에서 사용된 바이트에 대한 값을 지불.
4. 발신처에서 수신처로 트랜잭션 전송.
4.1 수신처 어카운트가 가 없으면 새로 생성
5. 수신처 어카운트가 컨트랙트이면 컨트랙트 코드를 끝까지 수행. 혹은 gas 소모까지 수행.
5.1 발신처가 코인이 모자라다면 원상태로 복귀
5.2 코드 수행시 gas가 모자라도 원상태로 복귀
-> 단, 수수료 지불은 제외되고 이 수수료는 채굴자 어카운트에 더해진다.
5.3 그 외에는 모든 남은 gas에 대한 수수료를 발신처에 돌려주고, 소모된 gas에 지불된 수수료를 채굴자에게 보낸다.
컨트랙트의 스토리지는 비어있다고 가정하고, 트랜잭션이 10 ether, 2000 gas, 0.001ether gasprice, 64 바이트의 데이터(0-31 바이트까지는 숫자 2를 나타내고, 32-63 바이트는 CHARLIE 라는 문자열)를 보낸다고 가정하자. 이 경우 상태 변환 함수의 프로세스는 다음과 같다.
트랜잭션이 유효하고 형식에 제대로 맞는지 확인한다.
트랜잭션 발송처가 최소 2000 * 0.001 = 2 ether를 가지고 있는지 확인하고, 그럴 경우, 발송처의 어카운트에서 2 ether를 뺀다.
gas = 2000으로 초기화 한 후, 트랜잭션은 170바이트 길이를 가지고, 바이트당 수수료는 5라고 가정하면, 850을 빼야 하고 결국 1150 gas가 남게된다.
발송처 어카운트에서 추가 10 ether를 빼고 이것을 컨트랙트 어카운트에 더한다.
코드를 실행시킨다. 이 경우는 간단한데, 컨트랙트의 index 2에 해당하는 스토리지가 사용되었는지 확인하고 (이 경우, 사용되지 않았다.) index 2에 해당하는 스토리지 값을 CHARLIE 로 설정한다. 이 작업에 187 gas 가 소비됐다고 가정하면, 남아있는 gas 의 양은 1150 - 187 = 963 이 된다.
963*0.001 = 0.963 ether를 송신처의 어카운트로 되돌려주고, 결과 상태를 반환한다.
트랜잭션의 수신처에 컨트랙트가 없으면, 총 트랜잭션 수수료는 제공된 GASPRICE와 트랜잭션의 바이트 수를 곱한 값과 같아지고, 트랜잭션과 함께 보내진 데이터는 관련이 없어지게 된다.
메시지는 트랜잭션과 마찬가지 방식으로, 상태를 원래 상태로 되돌린다는 것에 주목하자. 메시지 실행시 gas가 부족하게 되면, 그 메시지 실행과 그 실행에 의해 촉발된 다른 모든 실행들은 원래대로 되돌려지게 되지만, 그 부모 실행은 되돌려질 필요가 없다. 이것은 컨트랙트가 다른 컨트랙트를 호출하는 것은 안전하다는 것을 의미한다. A가 G gas를 가지고 B를 호출하면, A의 실행은 최대 G gas만을 잃는다는 것을 보장받게 된다. 컨트랙트를 생성하는 CREATE라는 opcode를 보면, 실행 방식은 대체로 CALL과 유사하나, 실행 결과는 새로 생성된 컨트랙트의 코드를 결정한다는 차이가 있다. (??) (메시지 이야기라 아직은 필요없을 것 같다.)
------
코드 실행(Code Execution)
------
이더리움 컨트랙트를 구성하는 코드는 EVM(Ethereum Virtual Machine)으로 쓰인다. (EVM은 Solidity가 컴파일하면 만들어지는 ABI) 튜링완전한 조건을 갖추기 위해 스택, 메모리, 저장소 등이 존재한다. 통상의 프로그래밍 언어와 유사함을 알 수 있다.
모든 계산 상태는 (block_state, transaction, message, code, memory, stack, pc, gas) 튜플(tuple)로 정의될 수 있다.
------
블록체인과 채굴(Blockchain and Mining)
------
이더리움 블록체인은 비트코인 블록체인과 유사하나 차이점이 있다. 이더리움 블록체인의 특징을 중점으로 기술.
주요 차이점: 트랜잭션 리스트와 가장 최근의 상태(state) 복사본을 가지고 있다.
블록넘버와 difficulty 또한 블록에 저장된다.
아래는 이더리움 블록 검증 알고리즘이다:
참조하고 있는 이전 블록이 존재하는지 그리고, 유효한지 확인한다.
현재 블록의 타임스탬프가 참조하고 있는 이전 블록의 그것보다 크면서, 동시에 현 시점을 기준으로 15분 후보다 작은 값인지 확인한다.
블록 넘버, difficulty, 트랜잭션 루트, 삼촌 루트, gas 리미트등(기타 다양한 이더리움 로우 레벨 개념)이 유효한지 확인한다.
블록에 포함된 작업 증명이 유효한지 확인한다.
S[0] 이 이전 블록의 마지막 상태(state)라고 가정 하자.
TX를 현재 블록의 n개의 트랜잭션 리스트라고 하자. 0 부터 n-1에 대해, S[i+1] = APPLY(S[i], TX[i]) 로 설정하자. 어플리케이션이 오류를 반환하거나, 이 시점까지 블록에서 소모된 총 gas가 GASLIMIT를 초과하면 오류를 반환한다.
채굴자에게 지불된 보상 블록을 S[n] 덧붙인 후 이것을 S_FINAL 이라 하자.
상태 S_FINAL의 머클 트리 루트가 블록 헤더가 가지고 있는 최종 상태 루트와 같은지를 검증한다. 이 값이 같으면 그 블록은 유효한 블록이며, 다르면 유효하지 않은 것으로 판단한다.
이러한 접근의 특징:
* 상태가 트리구조로 저장된다. 인접한 두 블록간의 트리 내용이 대부분 같고, 데이터가 저장되면 포인터(서브트리의 해시)를 써서 참조 가능. (해당 트리는 패트리시아 트리(Patricia Tree)로 부름)
컨트랙트 코드는 “어디에서" 실행되는가 : 컨트랙트 코드를 실행하는 프로세스는 상태 전환 함수 정의의 한 부분이고, 이것은 블록 검증 알고리즘의 부분이다. 따라서, 트랜잭션이 블록 B에 포함되면 그 트랜잭션에 의해 발생할 코드의 실행은 현재 또는 향후에 블록 B 를 다운로드 하고 검증하는 모든 노드들에 의해 실행될 것이다.
------
어플리케이션(Applications)
------
이더리움을 이용하여 총 세가지 카테고리의 어플리케이션을 제작할 수 있다.
금융 어플리케이션: 돈과 직접적으로 연관된 컨트랙트를 계약참여자로 하여금 보다 강력하게 설정-관리하게 한다. 하위화폐(=유로/달러 등의 상위화폐와 환율이 연동된 화폐를 지칭), 파생상품, 헷지컨트랙트, 예금용 전자지갑, 유언장, 그리고 최종적으로는 전면적인 고용계약 수준의 것들까지 포함한다.
준(準)금융 어플리케이션: 금전이 관여되어 있지만, 상당부분 비(非)화폐적인 면이 존재하는 계약을 위한 어플리케이션이 이에 해당된다. 이의 좋은 예로는 어려운 연산 문제를 푸는 자에게 자동적으로 포상금이 지급되는 계약이다.
온라인 투표와 분권형(分權形) 거버넌스(Governance)와 같이 금융과 관련성이 아예 없는 어플리케이션이 있다.
(이더리움 whitepaper 참조)
------
그 밖의 이슈들
------
------
결론
------
여기가 문서의 끝입니다.
끝.
------
Appendix A
------
비트코인 주소는 타원곡선공개키의 해시(the hash of the elliptic curve public key)이다.
------
Appendix B
------
"Casper"는 이더리움 차기 버젼이 도입할 POS 거래 / 블럭 검증 모델의 기반이 되는 consensus 알고리즘의 명칭입니다.
POW 시스템에서는 채굴자들이 블럭을 만들기 위해서 엄청난 전기에너지를 들이도록 해서 외부공격과 스팸 방지하여 Consensus Rule을 지키도록 하는데, POS는 Node들이 블럭을 만들기 위해서는 코인을 담보로 잡도록 하고, 사기치거나 스팸을 하다가 걸리면 담보로 잡힌 코인을 날리도록 해서 Consensus Rule을 지키도록 합니다.
Casper는 쉽게 말하자면 한 Node가 사기 치면, 다른 모든 Node들이 사기인지 아닌지 Consensus로 적발해서 처벌할 수 있도록 하는 Consensus Rule입니다.
Sharding은 이더리움 플랫폼의 거래 Capa 확대를 위해 현재 모든 거래를 모든 Node들이 다 검증하는 방식이 아닌, Node를 구획으로 나누어 구획별로 거래건을 검증하도록 하는 역할분담 모델입니다.
출처: https://www.clien.net/service/board/cm_vcoin/10905621