EOS EOSIO DApp 개발 – '나도 백서 읽는다' 시리즈 9. Inter Blockchain Communication

Inter Blockchain Communication

EOS.IO software is designed to facilitate inter-blockchain communication. This is achieved by making it easy to generate proof of Action existence and proof of Action sequence. These proofs combined with an application architecture designed around Action passing enables the details of inter-blockchain communication and proof validation to be hidden from application developers, enabling high level abstractions to be presented to developers.

블록체인 간 통신을 쉽게 할 수 있도록 설계했지. 어떻게? 액션 존재 증명과 액션 순서 증명을 쉽게 할 수 있도록 함으로. 이러한 방법은 높은 추상수준으로 제시됨으로 앱 개발자들은 상세사항을 알 필요가 없어.

Merkle Proofs for Light Client Validation (LCV)

블록체인에 연결되는 모든 클라이언트가 모든 블록을 가지고 증명에 참여하기를 원하지는 않아. 그래서 경량 클라이언트 검증이 필요하지.

Integrating with other blockchains is much easier if clients do not need to process all transactions. After all, an exchange only cares about transfers in and out of the exchange and nothing more. It would also be ideal if the exchange chain could utilize lightweight merkle proofs of deposit rather than having to trust its own block producers entirely. At the very least a chain's block producers would like to maintain the smallest possible overhead when synchronizing with another blockchain.

클라이언트가 모든 트랜잭션을 처리할 필요가 없다면다른 블록체인들과 통합은 쉬워지겠지. 거래소는 거래소로 들어오고 나가는 입출력에만 관심이 있겠지. 거래소는 블록 생산자를 전적으로 신뢰하기 위한 블록체인을 갖기 보다 거래소로 거래되는 거래에 대해서만 신뢰할 수 있는 블록체인을 갖기 원하겠지. 경량 머클 증명이 가능한 수준으로.
BP들도 당연히 다른 블록체인들과 동기화를 맞출 때 가능한 최소한의 오버헤드가 생기길 원하겠지.

The goal of LCV is to enable the generation of relatively light-weight proof of existence that can be validated by anyone tracking a relatively light-weight data set. In this case the objective is to prove that a particular transaction was included in a particular block and that the block is included in the verified history of a particular blockchain.

경량 클라이언트 검증의 목표는 상대적으로 적은 데이터셋을 추적해서 존재 증명이 가능하도록 하는 거지. 어떤 경우에? 특정 블록이 블록체인에 있는지, 특정 트랜잭션이 특정 블록에 포함되어 있는지 정도의 증명을 하려는 경우.

Bitcoin supports validation of transactions assuming all nodes have access to the full history of block headers which amounts to 4MB of block headers per year. At 10 transactions per second, a valid proof requires about 512 bytes. This works well for a blockchain with a 10 minute block interval, but is no longer "light" for blockchains with a 0.5 second block interval.

비트코인은 그렇지 않다는 것. 비트코인이 그렇게 할 수 있는 것에는 그럴만한 이유가 있다는 것. 10분 마다 블록이 생성되니까. 그런데 EOS는 다르 잖아. 0.5초 마다 블록이 생성되니.

The EOS.IO software enables lightweight proofs for anyone who has any irreversible block header after the point in which the transaction was included. Using the hash-linked structure shown it is possible to prove the existence of any transaction with a proof less than 1024 bytes in size.

비가역 블록에 포함된 트랜잭션은 블록 헤더 만으로도 증명이 가능하도록 했어. 1024 바이트 크기로도 어떤 트랜잭션이 존재하는지를 증명할 수 있도록 했어. 그림에서 보여지는 것처럼 해시 연결 구조를 사용해서.

Given any block id for a block in the blockchain, and the headers a trusted irreversible block. It is possible to prove that the block is included in the blockchain. This proof takes ceil(log2(N)) digests for its path, where N is the number of blocks in the chain. Given a digest method of SHA256, you can prove the existence of any block in a chain which contains 100 million blocks in 864 bytes.

*블록 id와 블록헤더 만으로 블록체인에 블록이 포함되었는지에 대한 증명이 가능 해. 머클 트리를 사용하니까, log2(N)으로 경로 추적을 줄일 수 있지.
SHA256를 사용하면 864 바이트에 1억 개의 블록을 포함하는 블록체인에 블록이 존재하는지를 증명할 수 있어. 대단해!

There is little incremental overhead associated with producing blocks with the proper hash-linking to enable these proofs which means there is no reason not to generate blocks this way.

물론 이를 위해서는 약간의 오버헤드가 생기지. 잃는 것보다 얻는 것이 크니 이렇게 하지 않을 이유가 없잖아.

When it comes time to validate proofs on other chains there are a wide variety of time/ space/ bandwidth optimizations that can be made. Tracking all block headers (420 MB/year) will keep proof sizes small. Tracking only recent headers can offer a trade off between minimal long-term storage and proof size. Alternatively, a blockchain can use a lazy evaluation approach where it remembers intermediate hashes of past proofs. New proofs only have to include links to the known sparse tree. The exact approach used will necessarily depend upon the percentage of foreign blocks that include transactions referenced by merkle proof.

다른 블록체인 상에서 증명을 검증 할 때 다양한 시간 / 공간 / 대역폭 최적화가 가능해. 블록헤더 만을 추적하는 것은 증명 크기를 작게 유지하도록 하지. 블록헤더는 년간 420MB 수준으로 증가 돼. 모바일 장치의 경우 시간이 좀 지나면 이것도 만만치 않은 양이 되겠는데. 이런 경우를 고려한 방법이 필요해.
최신 헤더만을 추적하는 방법도 있고. 과거 증명의 해시를 기억하는 지연 평가 방법을 사용할 수도 있고. 새로운 증명은 sparse tree에 대한 링크만 포함하게 할 수도 있겠지. sparse tree 이것도 우리말 하기 어렵네.
어떤 방식을 사용할지는 머클 증명에 의해 참조되는 트랜잭션들을 포함하는 외부 블록의 비율에 따라 결정될거야.

After a certain density of interconnectedness, it becomes more efficient to simply have one chain contain the entire block history of another chain and eliminate the need for proofs all together. For performance reasons, it is ideal to minimize the frequency of inter-chain proofs.

체인 간 증명의 빈도가 높아지면 성능상 문제가 있겠지. 그렇게 된다는 것은 증명할 거리가 많아 자체적으로 모든 블록을 가지고 있어야 하는데 그렇지 않다는 것을 나타내지.

Latency of Interchain Communication

When communicating with another outside blockchain, block producers must wait until there is 100% certainty that a transaction has been irreversibly confirmed by the other blockchain before accepting it as a valid input. Using an EOS.IO software-based blockchain and DPOS with 0.5 second blocks and the addition of Byzantine Fault Tolerant irreversibility, this takes approximately 0.5 second. If any chain's block producers do not wait for irreversibility it would be like an exchange crediting a deposit that was later reversed and could impact the validity of the blockchain's consensus. The EOS.IO Software uses both DPOS and aBFT to provide rapid irreversibility.

다른 블록체인과 통신할 때, BP들은 트랜잭션을 유효한 입력으로 받아들이기 전에 다른 블록체인에 의해 비가역적인 것으로 승인 되었음을 100% 확신될 때까지 기다려야 해. 신속한 비가역성을 제공하기 위해 DPOS와 aBTF를 사용해. DPOS 방식으로 블록 생산하는데 0.5초, aBTF로 비가역성에 거의 0.5초. 이 정도면 기다릴 만한 시간이지. 기다리는 게 좋아.

Proof of Completeness

When using merkle proofs from outside blockchains, there is a significant difference between knowing that all transactions processed are valid and knowing that no transactions have been skipped or omitted. While it is impossible to prove that all of the most recent transactions are known, it is possible to prove that there have been no gaps in the transaction history. The EOS.IO software facilitates this by assigning a sequence number to every Action delivered to every account. A user can use these sequence numbers to prove that all Actions intended for a particular account have been processed and that they were processed in order.

다른 블록체인에서 머클 증명을 사용할 때, 생략되거나 스킵된 트랜잭션이 없다는 것을 아는 것은 불가능하지만 처리된 트랜잭션이 유효하다는 것을 증명하는 것은 가능해.
모든 계정에 전달되는 모든 액션들에 일련번호를 할당함으로 가능하지. 사용자는 일련번호를 사용해서 특정 계정을 대상으로하는 모든 액션이 순서대로 처리되었음을 증명할 수 있어.

Segregated Witness

The concept of Segregated Witness (SegWit) is that transaction signatures are not relevant after a transaction is immutably included in the blockchain. Once it is immutable the signature data can be pruned and everyone else can still derive the current state. Since signatures represent a large percentage of most transactions, SegWit represents a significant savings in disk usage and syncing time.

트랜잭션이 비가역적으로 블록체인에 포함되었다는 것은 트랜잭션이 유효성이 이미 검증되었다는 거지. 서명은 트랜잭션의 유효성을 검증하기 위한 것이니 비가역적인 상태가 되면 블록체인 상태와는 별 관계가 없다는 거지. 서명이 있고 없고는 블록체인의 현재 상태를 얻는 것과는 아무 상관이 없지.
트랜잭션에서 서명은 큰 부분을 포함하기 때문에 트랜잭션에서 서명을 분리해 낸다면 디스크 사용과 동기화 시간을 상당히 줄일 수 있지.

This same concept can apply to merkle proofs used for inter-blockchain communication. Once a proof is accepted and irreversibly logged into the blockchain, the 2KB of sha256 hashes used by the proof are no longer necessary to derive the proper blockchain state. In the case of inter-blockchain communication, this savings is 32x greater than the savings on normal signatures.

이 개념은 머클 증명에도 적용될 수 있지. 이렇게 하면 sha256의 2KB정도를 줄일 수 있게 되는데, 이것은 일반적인 서명에 대한 절약보다 32배 더 커.

Another example of SegWit would be for Steem blog posts. Under this model a post would contain only the sha256(blog content) and the blog content would be in the segregated witness data. The block producer would verify that the content exists and has the given hash, but the blog content would not need to be stored in order to recover the current state from the blockchain log. This enables proof that the content was once known without having to store said content forever.

세그윗의 또 다른 예로 스팀 블로그 게시글이 있지. 이 모델에서 게시글에는 sha256만 포함하고, 글내용은 분리된 증인 데이터에 포함 돼. BP는 글내용이 있고, 해시가 있는지 검증하지만 글내용을 블록체인에 저장하지는 않아. 글내용은 블록체인 로그를 통해 현재 상태를 복구할 때 사용하지 않는다는 거지. 이렇게 함으로 글내용을 블록체인에 영원히 저장하지 않고도 글내용을 증명할 수 있게 하지.