본 문서는 Ruben Somsen에 의해 작성된 "소프트체인: 작업증명(PoW) 사기 증명을 통한 소프트 포크로서의 사이드체인(Softchains: Sidechains as a Soft Fork via Proof-of-Work Fraud Proofs)을 한글로 번역하여 한국 개발자 커뮤니티에서 보다 효과적인 논의 및 토론을 만들어 나가기 위해 번역된 문서임을 명시합니다.
원래 이 글은 비트코인 개발자 메일링 리스트에 게시됨.
이 게시물은 완전히 분산된 양방향 페그 사이드체인 설계를 설명합니다. 새로운 사이드체인을 활성화하려면 소프트 포크가 필요하므로 '소프트체인'이라는 이름이 붙었습니다. 핵심적인 측면은 모든 소프트체인이 작업증명(PoW) 사기 증명(PoW FP)을 통해 모든 사람에 의해 검증된다는 것입니다. 이는 느리지만 매우 효율적인 합의 메커니즘으로, 논쟁이 되는 블록만 검증하면 됩니다. 이는 메인체인 풀 노드의 검증 부담을 약간 증가시키지만, 연간 체인당 약 100MB 정도로 최소화됩니다. 이는 드라이브체인과 유사하지만, 모든 비트코인 풀 노드 사용자가 각 사이드체인을 효율적으로 검증할 수 있기 때문에 채굴자에게 의존해야 하는 주요 단점이 없습니다.
작년에 비트코인 메일링 리스트에 PoW FP 아이디어를 게시했습니다(후속 게시물 여기 참조). 이 아이디어는 비트코인의 PoW에서 포크가 존재한다는 사실을 블록이 유효하지 않을 가능성이 있는 증거로 사용할 수 있다는 것입니다(즉, 잠재적 사기의 증거). 이러한 일이 발생할 때마다 문제의 블록을 다운로드하여 유효(및 사용 가능)한지 확인하고, 그렇지 않은 경우 이를 거부합니다. 우리는 UTXO 세트 커밋먼트(예: utreexo)를 유지할 필요 없이, 두 포크 모두에 존재하는 마지막 블록 내부의 커밋이 유효하다고 가정합니다. 결과적으로, 우리는 고아 블록만큼의 블록(및 해당 UTXO 세트 증명)만 다운로드하면 되므로 풀 노드를 실행하는 것에 비해 검증 비용이 상당히 낮아집니다.
지난 4개월 동안 Forkmonitor는 11개의 유효하지 않은 블록과 스테일 블록을 등록했습니다. 이러한 데이터를 기반으로 추정하면, 비트코인 합의를 검증하는 PoW FP 노드는 합의 보장을 받기 위해 연간 약 100MB 이상의 데이터를 다운로드하고 검증해야 하고 이는 풀 노드에 가까운 수준입니다 :
- 모든 PoW 헤더 (~연간 4MB)
- 3 x 11 = 33개의 전체 블록 (~2MB x 33 = 66MB)
- UTXO 머클 증명 (~1MB x 33 = 33MB, utreexo 사용 시)
합의가 느리다고 간주되는 이유는 정직한 소수의 PoW가 유효하지 않은 체인으로부터 포크할 시간을 주어야 하기 때문입니다. 만약 전체 채굴자의 1%만 정직하다고 가정하면, 합의가 100배 느려집니다. 보통 6개의 확인을 기다리는 것이 만족스러웠다면, 이제는 600개의 확인을 기다려야 합니다. 기다리는 시간이 길어질수록 정직한 채굴자가 필요하지 않습니다.
양방향 페그 사이드체인을 가지려면 페그 아웃이 유효하다는 것을 메인체인에 증명하는 간결한 방법이 필요합니다. PoW FP는 저대역폭 방식으로 체인이 유효한지, 따라서 페그 아웃이 유효한지를 결정할 수 있는 방법을 제공합니다. PoW FP 합의의 느림은 문제가 되지 않으며, 페그 아웃은 임의로 느리게 만들 수 있습니다 (예: 1년).
가장 안전한 설계는 비트코인 코어와 합의 코드를 공유하는 소프트체인 세트를 사용하는 것입니다. 여기에는 UTXO 세트 커밋먼트를 추가하고, 특정 자원 사용 문제를 최소화하기 위해 비탭루트 주소 유형을 비활성화하는 것이 포함됩니다. 모든 사용자는 기존처럼 풀 노드로 메인체인을 검증하고, 모든 소프트체인은 PoW FP 합의로 검증됩니다. 사용자가 특정 소프트체인을 직접 사용하고자 한다면, 빠른 합의를 얻기 위해 해당 소프트체인을 풀 노드로 실행해야 합니다.
페그 인은 메인체인에서 코인을 동결하고 이를 소프트체인에 할당함으로써 발생합니다. 페그 아웃은 소프트체인에서 페그 아웃 거래를 가리키는 메인체인 거래를 생성하고 충분한 수의 메인체인 확인을 기다림으로써 발생합니다. 페그 아웃 거래가 PoW FP 합의에 따라 소프트체인의 일부로 남아 있으면, 코인은 사용 가능해집니다.
페그 인/페그 아웃 메커니즘 자체는 소프트 포크가 필요하며 (정확한 설계는 아직 미정), 이후 활성화되는 모든 소프트체인도 소프트 포크가 필요합니다.
소프트체인 합의는 여전히 메인체인 사용자로부터 검증을 필요로 하며, 이로 인해 합의 버그가 부정적인 영향을 미칠 수 있습니다. 특히, 소프트체인이 비결정론적 합의 버그를 겪는 경우, 다수는 페그 아웃을 수용하는 반면 소수는 이를 거부할 수 있습니다. 이러한 특정 상황은 메인체인 합의에서 체인 분리를 초래할 수 있습니다. 따라서 소프트체인 설계는 비트코인 코어를 기반으로 하는 것이 가장 안전할 것입니다.
유사하게, 소프트체인이 주요 재조직(reorg)을 겪어 페그 아웃이 메인체인에서 수용되기 직전에 무효화될 가능성도 이론적으로 존재합니다. 이로 인해 합의가 분리될 수 있습니다. 느린 페그 아웃 과정은 이런 상황을 점점 더 불가능하게 만들지만, 여전히 완전히 배제할 수는 없습니다. 도움이 될 수도 (혹은 오히려 더 악화시킬 수도) 있는 방법 중 하나는 페그 아웃 시간의 절반 (예: 페그 아웃이 1년인 경우, 반년)보다 큰 재조직을 금지하는 합의 규칙을 도입하는 것입니다. 이러한 규칙은 실제로 합의 문제를 해결하지는 않지만, 문제를 소프트체인에서 먼저 발생하게 하여 메인체인에 영향을 미치기 전에 조치를 취할 시간을 제공할 수 있습니다.
각 소프트체인이 비트코인 네트워크의 해시레이트와 같은 충분한 양의 작업증명(PoW)을 생성하는 것도 중요합니다. 만약 난이도가 너무 낮으면, 포크를 생성하는 비용이 줄어들고 PoW FP 합의의 자원 사용이 증가할 수 있습니다. 따라서 소프트체인 블록에 대해 최소 허용 난이도를 설정하여 수수료가 충분하지 않을 때 체인이 느려지게 하는 것이 좋을 수 있습니다. 병합 채굴(Merged Mining) 도 여기에서 도움이 될 수 있습니다. 병합 채굴을 통해 소프트체인이 비트코인과 동일한 해시레이트를 받을 수 있을 가능성이 있지만 (모든 채굴자가 참여한다고 가정할 때), 이는 또한 채굴자에게 추가적인 검증 부담을 줄 수 있습니다.
위에서 설명한 합의 위험이 이 기술을 지나치게 위험하게 만들 수도 있지만, 적어도 가능성을 탐색해 볼 가치가 있어 보입니다. 최소한 더 많은 선택적 블록 공간을 제공할 것이며, 전혀 다른 합의 규칙을 가진 체인으로의 길을 열어줄 가능성도 있습니다.
제 작업을 읽고 이해해 주셔서 감사합니다. 질문이 있으시면 기꺼이 답변해 드리겠습니다. 제가 간과했을 수 있는 문제들에 대한 피드백과 문제를 완화하여 최대한의 안전성을 보장할 수 있는 아이디어를 기다리겠습니다.
이 기술이 분산형 양방향 페그 사이드체인이 현실에 한 걸음 더 다가가는 데 도움이 되기를 바랍니다.
모두 새해 복 많이 받으세요.
-- 루벤 솜센(Ruben Somsen)
아래의 글은 루벤 솜센의 영어원문에서 포크하여 가져온 글 입니다.
Originally posted on bitcoin-dev.
This post describes a fully decentralized two-way peg sidechain design. Activating new sidechains requires a soft fork, hence the name softchains. The key aspect is that all softchains are validated by everyone via Proof-of-Work Fraud Proofs (PoW FP) -- a slow but very efficient consensus mechanism that only requires the validation of disputed blocks. This does increase the validation burden of mainchain full nodes, but only by a minimal amount (~100MB per chain per year). It's similar to drivechains, but without the major downside of having to rely on miners, since all Bitcoin full node users can efficiently validate each sidechain.
Last year I posted the idea of PoW FP to the Bitcoin mailing list (follow-up here). The idea is that we can use the existence of a fork in Bitcoin's PoW as evidence that a block might be invalid (i.e. a proof of potential fraud). Whenever this occurs, we download the block in question to verify whether it was valid (and available), and reject it if it was not. We forego the need for maintaining a UTXO set with UTXO set commitments (such as utreexo), by assuming that the commitment inside the last block to exist in both forks is valid. As a result, we only need to download as many blocks (and their corresponding UTXO set proofs) as there are orphans, which lowers the validation costs considerably compared to running a full node.
In the past 4 months, Forkmonitor has registered 11 stale and invalid blocks. Extrapolating from that data, a PoW FP node verifying Bitcoin consensus would have to download and verify a little over 100MB per year in order to have consensus guarantees that come close to that of a full node:
- All PoW headers (~4MB per year)
- 3 x 11 = 33 full blocks (~2MB x 33 = 66MB)
- UTXO merkle proofs (~1MB x 33 = 33MB with utreexo)
The reason consensus is considered slow, is because we need to allow time for a honest PoW minority to fork away from an invalid chain. If we assume only 1% of all miners are honest, this means consensus slows down by 100x. If you are normally satisfied waiting for 6 confirmations, you now need to wait 600 confirmations. The longer you wait, the fewer honest miners you need.
In order to have two-way pegged sidechains, you need a succinct method for proving to the mainchain that a peg-out is valid. PoW FP provides exactly that -- a low-bandwidth way of determining if a chain, and thus a peg-out, is valid. The slowness of PoW FP consensus is not an issue, as peg-outs can be made arbitrarily slow (e.g. one year).
The safest design would be a set of softchains that shares its consensus code with Bitcoin Core, with the addition of UTXO set commitments, and disabling non-taproot address types to minimize certain resource usage issues. All users validate the mainchain as usual with their full node, and all softchains are validated with PoW FP consensus. If a user is interested in directly using a specific softchain, they should run it as a full node in order to get fast consensus.
Peg-ins occur by freezing coins on the mainchain and assigning them to a softchain. Peg-outs occur by creating a mainchain transaction that points to a peg-out transaction on a softchain and waiting for a sufficient number of mainchain confirmations. If the peg-out transaction remains part of the softchain according to PoW FP consensus, the coins become spendable.
The peg-in/peg-out mechanism itself would require a soft fork (the exact design is an open question), and subsequently every softchain that gets activated will also require a soft fork.
Softchain consensus still requires a form of validation from mainchain users, which means that consensus bugs can have an adverse effect. In particular, if a softchain suffers from a non-deterministic consensus bug, it may be the case that a majority accepts a peg-out, while a minority rejects it. This specific scenario could cause a chain split in mainchain consensus. This is why it would be safest to base softchain designs on Bitcoin Core.
Similarly, it can theoretically be possible that a softchain gets a major reorg, invalidating a peg-out right as it would have become accepted on the mainchain, thus splitting consensus. The slow peg-out process makes this increasingly unlikely, but not impossible. One thing that might help (or perhaps only make it worse) is introducing a consensus rule that disallows reorgs that are bigger than half the peg-out time (e.g. half a year, if the peg-out is one year). This kind of rule does not actually solve this consensus problem, but instead pushes the problem forward so it plays out first on the softchain, giving time to take action before the problem affects the mainchain.
It is also important that each softchain produces a non-trivial amount of PoW, because if the difficulty is too low, the cost of creating forks and increasing the resource usage of PoW FP consensus goes down. It may therefore make sense to have a minimum accepted difficulty for softchain blocks (slowing down the chain when fees are not sufficient). Merged Mining could also help here, since that would allow the softchains to potentially receive the same hashrate as Bitcoin (assuming all miners participate), but of course this would also put an additional validation burden on miners.
It may turn out that the consensus risks outlined above make this prohibitively risky, but at the very least it seems worth exploring the possibilities. At a minimum it would provide more opt-in block space, and it could potentially open the door to chains with entirely different consensus rules.
Thank you for taking the time to read and comprehend my work. I will happily answer any questions and I look forward to any feedback on issues that I might have overlooked, and ideas on mitigating problems to ensure maximum safety.
Hopefully this will bring decentralized two-way peg sidechains one step closer to becoming a reality.
Happy new year, everyone.
-- Ruben Somsen