Reorg Caps와 Confirmation Delays: 공정성 중재에 대한 입문서


이러한 용어 중 하나에 따라, 해당 값은 분산된 작업증명(Proof-of-Work) 네트워크의 클라이언트(노드)가 불변한 체인 데이터와 그렇지 않은 체인 데이터를 구별하기 위해 사용할 창구의 한계를 정의한다.

상기의 ‘불변’이라는 단어를 작업 증명 블록체인 데이터가 늘 ‘완벽하게 불변’하다는 직감이나 함축으로 오해하고 있다면, 우리는 먼저 이 일반적인 오해를 극복해야 한다.

이더리움 클래식의 불변성에 대한 약속은 체인 데이터의 특정 집합(완전한 거나 부분적으로)을 직접 지칭하지 않는다. 대신 그것은 네트워크와 데이터베이스 프로토콜을 설계대로 계속 추진하겠다는 의도를 나타낸다. 실제로, 유명한 황서(Yellow Paper)에서는 Proof-of-Work 프로토콜에 기초한 합의를 이더리움(이더리움 클래식)의 규범으로 묘사하고 있는데, 이 합의는 어떤 노드에서도 데이터의 지속성을 가정하지 않는 것에 크게 의존하고 있다.

노드는 정성적으로 정의된 합의 규칙을 사용하여 독립적으로 도달하는 등 효력 있는 데이터 상태이기 때문에 이러한 합의 규칙의 가변 도메인은 링크된 데이터 자체의 내재된 부분에만 존재하며, 이러한 합의 규칙은 규범 파생 함수를 사용하여 검증하고 생성할 수 있다. 이 값에는 [total difficulty]. [mix hash], [state root] 등이 포함된다.

체인 데이터의 이러한 특징 검증은 노드가 공통 링크 데이터 상태에 도달하기 위한 유일한 조건으로, 이를 통해 네트워크는 분산된 비잔틴 내결함성을 달성할 수 있다. 노드들은 영원히 다른 노드, 노드 그룹에 강제적으로 의존하지 않으며, 네트워크 상태에 대한 단일한 임시 이해에도 의존하지 않는다. 노드는 1분 또는 일주일 동안 속일 수 있지만, 장기적으로는(선량한 노드와 채굴자) 명확한 네트워크 정의가 부여된다는 조건 아래의 공통된 진리이자 공감대이다.

Reorg caps(재구성 한계)

Reorg caps는 프로토콜에서 정의 되지 않은 프로토콜 외부적 변수이며, 노드에서는 이 변수를 사용하여 링크된 데이터 상태의 지속성을 임의로 가정할 수 있다. 다시 말하자면 이것은 합의 규칙을 벗어난 가정을 나타낸다. 더욱이 우리가 보게 될 것처럼 실제 이 합의의 합의 규칙과 직접적으로 모순될 수도 있다.

노드 A의 Reorg caps 이 3,000블록이라고 가정하면 이는 최신 체인의 숫자가 10,000이라고 판단될 경우 노드 A는 6,999 또는 그 이하의 블록 중 공통된 조상의 어떤 유효 체인을 거부한다는 의미가 된다. 이 새 체인이 10,000블록의 길이를 가졌더라도 Total difficulty는 10,000,000배에 달하고, 규범이 정의한 블록 상속 공감대 규칙에 따라 완전히 유효하다.

이제, 노드 B가 3,000개의 블록을 같은 Reorg caps를 가지고 있다고 가정한다, 그러나 노드 B는 물리적으로 채굴자 바로 옆에 위치했으며 블록 넘버 10.001을 노드 A보다 먼저 도입한다. 그리고 어떤 기적이나 비극을 통해 100,000개의 긴 사슬이 발표되고, 노드 A와 노드 B 모두에서 새로운 후보 사슬의 소식을 듣는다. 새로운 체인은 7,000블록에서 A와 B 동시에 두 노드의 조상을 갖게 된다.

이 경우, 노드 A의 최신 블록은 10,000이며 공통 조상에 3,000(10,000-3,000=7,000)의 Reorg caps를 허용하고 유효하고 새로운 10,000 블록체인을 다운로드 하기 위해 블록 데이터베이스를 재구성한다. 반면 노드 B는 이미 블록 10,001(확실히 전파된 10만 번째 블록보다 열세지만 완벽하게 유효한 블록)을 이미 가져온 경우 3,000개의 Reorg caps를 변경되지 않도록 하므로 블록 7,001 아래의 블록 재구성을 거부한다. 노드 B는 이제 100,000개의 블록체인과 동기화할 수 없으며, 이 합의는 실패로 끝나게 된다.

즉, 노드 B의 운영자가 트위터에서 일시적인 증거를 신뢰하고, 이 노드에서 이미 다운로드한 체인 데이터를 제거한 뒤 다시 인터넷과 동기화를 시도하기로 한 것이다. 이 경우 100,000개 블록체인을 검증하고 도입할 수 있으며, 노드 A와 공감대를 형성할 수 있다. 100,000블록 체인을 하나 또는 여러 개의 대등 노드가 수신하거나 처리할 수 있을 때까지 짧은 10,001개의 체인을 보고하면 두 번째 동시 시도는 다시 실패한다. 이 경우 노드 운영자는 다시 오라클을 점검해야 한다.

이처럼 노드 B의 공감대 문제는 네트워크의 임시적이고 주관적인 뷰를 수동으로 덮어쓰는 것으로 해결할 수 있기 때문에 Reorg caps는 유연한 최종 임곗값으로 이해된다.

Reorg caps의 이론과 실천

이론상으로는 이더리움이나 이더리움 클래식의 PoW 블록체인 프로토콜에는 Reorg Cap에 대한 사향이나 상한선이 없다. 위의 설명을 통해 명확하게 이해되었기를 바라며, 실제로는 합의 프로토콜의 기본 가정과 이론은 모순된다.

실제로 Open Ethereum의 Reorg caps는 분명히 3,000이다. 2020년 채굴자 한 명이 이더리움 클래식 네트워크에서 유용한 3,671블록 사슬을 송출할 때 Open Ethereum 노드에서 정확한 합의의 네트워크 상태를 확인할 수 없는 비합의의 영향으로 사슬이 분열되었다.

‘FullImmmutability’라 불리는 Reorg caps(빠른 동기화 및 전체 동기화 구성용) 및 LightImftability Caps(LES 구성의 경우)는 Core-Geth와 Ethereum/go-Ethereum에도 존재하며 각각 90,000과 30,000으로 설정된다. 체인 데이터 합의와 관련하여 이러한 값은 ‘매우 높은’ 값으로 가정되고 의도적으로 설계되며, 이는 실제로 동기화 프로토콜에 사용되어서는 안 된다는 개발자가 원하는 가정을 나타낸다. 이러한 값은 데이터베이스 최적화의 실용성, 즉 체인 데이터를 두 개의 데이터베이스로 분리하는 것을 용이하게 하기 위해 존재한다. 이는 ‘Ancient Store’ 불리며, 디스크 사용과 입출력을 최적화하면서 아카이브 체인 데이터를 저장하도록 설계된 불변의 데이터 저장소다. 이 제한치(예:100블록 체인의 909,999블록)이하로 떨어지는 블록은 Ancient Store로 이동하기에 안전한 것으로 간주되어 프로그램의 디스크 용량을 최적화한다.

만약 한 명의 채굴자가 100,000개의 새롭고 효율적이며, 난도 높은 블록의 사슬을 네트워크에 경이롭게 송출할 경우 Open Ethereum, Core-Geth, go-Ethereum 모두 심각한 공격을 받게 될 것이다. 공감대를 통한 난이도 알고리즘을 통해 90,000개 블록의 체인은 약 2주의 채굴 기간이 필요하다.

Reorg Caps와 Confirmation Delays

Reorg Caps는 통상적으로 거래소에서 사용자에게 확인하는 입출금 지연과 관련이 있다. 거래소는 컨펌 지연을 통해 특정 체인에서 최종 승인된 계정 입금 및 인출에 대한 거래 보안창을 결정한다. 일단 거래가 체인 네트워크에 의해 처리되면 후속 체인 재구성이 지연된 확인 내에서 발생하면, 거래소는 거래소에서 거래를 중단하고 사용자에게 다시 시도하도록 요구하여 거래소와 사용자의 손실을 예방할 수 있다.

거래소에 의해 구현된 컨펌은 체인과 관련된 가정된 위험 정도를 나타낸다. 건전하고 경쟁력 있는 거래소는 주어진 체인에 대해 다양한 실시간 검증(예: 해시레이트, 트랜잭션 처리량, 과거 변동성)을 사용해 위험에 대한 적절한 대응을 할 수 있다. 일부 체인은 경쟁을 부추겨 위험 방지의 문턱을 낮추고 싶어 하지만 다른 체인은 더 보수적인 입장을 취하기도 한다.

Reorg caps는 임의의 체인 세그먼트에 대해 불변성을 적용하여 네트워크 합의 사양에 대한 노드 구현을 잠재적으로 저해할 수 있다. Reorg caps와 같은 확인 지연은 최종석에 대한 주관적인 결정이다. 그러나 Reorg caps와 달리 확인 지연은 오프 체인(예:인출에 대한 명목 지불)의 주권적 행동을 제한하는 반면, 노드 재구성 한도는 온체인 네트워크에 영향을 미쳐 행위 상태에 영향을 미칠 수 있다.

FAQs

질문: 동등한 거래소 Confirmation Delays와 클라이언트 Reorg caps가 51%가 공격을 방지할 수 있을까?

답: 우리는 모든 거래소가 같은 Confirmation Delays를 채택하기를 희망하지도 장려하지도 않는다. 위에서 설명한 것과 같이 Reorg caps는 네트워크 수준에서 구현이 불가능하며, 노드는 분산되고 합의 메커니즘은 각 노드가 같은 합의 알고리즘을 독립적으로 비동기적으로 사용하여 같은 체인 상태에 도달하는 능력에 의존하고 있기 때문이다. 실행 가능한 Reorg caps를 구현하는 클라이언트(노드)는 자신과 전체 네트워크 상태에 뚜렷한 위협을 나타낸다. 반면 확인 가치는 교환의 위험을 완화할 수 있는 훌륭한 방법이다. 고객의 Reorg caps는 위험을 완화하지 않는다. 즉, 그들은 필요한 합의 기능을 잠재적으로 적대시하고 금지함으로써 위험을 증가시킨다.

질문: 하드포크는 사용할 경우 구성 값으로 Reorg caps를 구현할 수 있나?

답: 그렇지 않다. 그럴 수 있어도 절대 아니다. 특정 하드포크 블록(숫자)의 사용이 가능해지면 특정 Reorg caps를 구성할 수 있다. 그리고 이론적으로 클라이언트에 대한 코드를 작성해 그들이 모두 같은 Reorg caps를 사용하도록 하고 같은 하드포크 번호로 활성화할 수 있다. 그러나 모든 노드가 같은 Reorg caps 사용하지만, 서로 일치하는 방식으로 그러한 논리를 반드시 활용하지 않는다는 것을 의미한다. 해당 논리는 노드에 대해 구현할 수는 있지만 전체 네트워크에서는 구현할 수 없다.

질문: 어떤 Reorg caps 사용해야 하나?

답: ETC Labs는 이더리움 클래식을 사용할 숫자를 결정할 때 거래소의 조언을 자주 듣는다. 우리는 절대 숫자를 제공하지 않는다. 이는 거래소의 위험 관리 평가 능력을 직접적으로 나타내는 가치로서 우리가 결정할 사항이 아니다. 우리의 업무는 체인 및 네트워크가 설계한 대로 기능하고 설계 및 프로토콜에 대한 정보가 접근할 수 있고 실행 가능한지 확인하기 위해 할 수 있는 일을 하는 것이다. 그러나 기관과 개인 모두 사용자들이 정보에 입각한 의사결정을 할 수 있도록 돕기 위해서만 체인을 어떻게 사용하는지 누군가에게 말하는 것은 우리의 업무가 될 수 없으며 또 해서는 안 된다.

Recent Posts

See All