CoinEx 리서치: 블록체인 자산의 보안 딜레마: 실제 시간이 추가 보안 계층으로 필요한 이유

2020년 디파이 썸머 이후, 블록체인 인프라의 지속적인 발전에 힘입어 디파이 프로토콜은 스왑에서 대출, 수익 농사에 이르기까지 점차 정교한 프로토콜로 진화했습니다. 이는 블록체인 파생상품 기반의 AMM(자동화된 시장 조성) 수익 농사 전략, 대출 인프라 기반의 구조화된 대출 플랫폼, 실물 담보와 연계된 온체인 대출 프로토콜 등을 포함합니다.

디파이 혁신의 붐을 일으킨 주요 요인 중 하나는 '컴포저빌리티(조합 가능성)'라는 개념입니다. 대부분의 경우, 새로운 디파이 프로토콜이 출시될 때 그 소스 코드도 공개됩니다. 이는 하나 이상의 디파이 프로토콜의 스마트 컨트랙트 소스 코드를 쉽게 조합하여 새로운 프로토콜을 만들 수 있다는 것을 의미합니다. 이는 마치 레고 블록과 같아서, 서로 다른 모양의 블록들을 조합하여 독특한 프로젝트를 만들 수 있으며, 이는 혁신 비용을 크게 낮춥니다.

놀랍게도, 이러한 대규모 혁신에도 불구하고 2020년 이후 디파이 사용자 수는 큰 증가를 보이지 않았습니다. 한편, 전통적인 기관들은 블록체인 공간에 유동성을 투입하지 않았습니다. 이러한 현상의 주요 원인 중 하나는 디파이의 보안 문제입니다.

현실 세계의 금융은 잘 확립된 안전한 시스템을 갖추고 있습니다. 예를 들어, A은행에서 B은행으로 자금을 이동할 때, 현금 수송차와 무장 경찰이 자금을 안전하게 보호하며, 이는 안심할 수 있는 과정입니다. 또한, 은행들은 고객의 자산에 대해 책임을 지며 과정 중 발생하는 손실에 대해 보상을 제공합니다. 그러나 디파이는 기존 금융 시스템과 다릅니다. 스마트 컨트랙트는 본질적으로 변경이 불가능하도록 설계되어 있습니다. 이들은 본질적으로 읽을 수 있는 로그를 보내지 않는 블랙박스이므로, 사람들은 내부 프로세스를 명확하게 볼 수 없습니다. 대부분의 스마트 컨트랙트 감사는 발생 가능성이 높은 새로운 유형의 결함이 아닌 알려진 형태의 공격에만 초점을 맞추기 때문에 도움이 되지 않습니다. 한편, 많은 디파이 프로토콜들은 자신들을 "본인 책임 하에 사용하는" 제품으로 표시합니다. 이는 일반 사용자들에게 두려움을 줄 수 있으며, 그들의 은행 예금 대부분을 디파이 생태계에 투자할 자신감을 잃게 만듭니다. 디파이는 그것을 신뢰하지 않았던 사람들을 실망시키지 않았습니다. 지금까지 디파이는 82건의 보안 침해를 겪었으며, 초기 해킹 금액은 18억 달러 이상입니다. 특히 플래시 론이 가장 일반적인 공격 유형으로, 33건을 차지합니다. 플래시 론 공격 배후의 보안상 이유 중 하나는 블록체인에서 정확한 시간 개념과 확인 메커니즘의 부재 입니다. 이에 대한 구체적인 이유는 다음 장에서 살펴보겠습니다.

I. 시간 & 컴퓨터의 시간 네트워크

먼저 기존 컴퓨터 프로그램에서 시간이 어떻게 작동하는지 살펴보겠습니다.

시간은 컴퓨터 프로그램에서 필수적인 개념입니다. 시간 개념이 없다면 TLS 활성화 웹사이트에 접속하거나, 특정 알고리즘을 위한 엔트로피를 생성하거나, 비밀을 교환하거나, Windows 라이선스를 인증하는 것이 불가능합니다. 우리는 컴퓨터의 시간 유지를 당연하게 여기지만, 실제 운영에 있어 시간을 교환하고 추적하는 것은 믿을 수 없을 만큼 어려운 문제입니다.

시간은 본질적으로 우주의 현재 전역 상태를 나타냅니다. 이는 주어진 순간에 모든 개체가 정확히 동일한 값을 공유해야 한다는 것을 의미합니다. 이는 컴퓨터에게 명백히 큰 문제입니다: 우주의 중심에 매우 정확한 원자시계가 있어 인터넷을 통해 시간 데이터를 전송한다고 가정해 봅시다. 이 과정에서의 문제는 데이터 전송 자체에 시간이 걸린다는 것입니다. 기기가 인터넷을 통해 시간 데이터를 받아 자체 시스템에 적용할 때쯤이면, 우주의 전역 상태(시간)는 이미 변경되었을 것입니다. 다시 말해, 네트워크 기기가 실제 전역 시간 값과 완벽하게 동기화되는 것은 불가능합니다.

네트워크 시간 유지의 또 다른 문제는 데이터 전송에 필요한 시간을 완벽하게 예측할 수 없다는 것입니다 - 네트워크 상태는 계속 변화하며, 실제 환경에서 완벽한 신뢰성을 보장할 수 있는 사람은 없습니다. 첫 번째 문제와 결합하면, 이는 수신자가 시간 값을 완벽하게 복제할 수 없다는 것을 의미하며, 이는 불일치를 초래합니다.

네트워크 시간 프로토콜(NTP)은 전 세계에 분산된 시간 서버들의 상호 검증 구조(최대 15개의 계층)와 벨만-포드 최단 경로 스패닝 트리(지연 시간과 전송 시간 불일치를 모두 줄임)를 구축함으로써 이 문제를 해결합니다. 이는 개인용 컴퓨터와 중앙 집중식 서비스, 특히 정확한 타이밍에 의존하는 애플리케이션(예: 암호화 프로그램)에 완벽하게 작동합니다. NTP를 통해 얻은 타임스탬프가 추정치에 불과하더라도, 시간에 민감한 애플리케이션이 의존할 만큼 충분히 정확하고 성숙합니다.

출처: https://medium.com/@gokhansengun/bilgisayarlar-zaman%C4%B1-nas%C4%B1l-do%C4%9Fru-tutar-78c1203397f0

II. 블록체인 네트워크의 시간 메커니즘

블록체인에도 시간 개념이 존재합니다. 블록체인 자체가 시간 개념의 파생물이라고 말하는 사람들도 있지만, 블록체인 네트워크의 시간 처리는 NTP 시스템의 64비트 정확도에 비해 매우 부정확합니다. 결국 이는 블록체인 시간의 서비스 대상이 디파이 애플리케이션과 같은 시간에 민감한 스마트 컨트랙트 애플리케이션이 아니기 때문이기도 합니다. 또한 합의 메커니즘의 안전하고 효율적인 실행을 가능하게 하는 것을 목표로 합니다. 이러한 다른 목표로 인해 블록체인 네트워크는 시간 부정확성에 더 관대합니다. 다음 단락에서는 몇 가지 인기 있는 합의 메커니즘과 이들이 시간을 결정하는 방법에 대해 논의하겠습니다. 다만, 블록체인의 시간 확인이 매우 부정확하여 수백억 달러 가치의 온체인 자산에 대한 금융 운영과 보안 검사를 수행할 수 없다는 점에 주목해야 합니다.

1. 비트코인

비트코인은 작업증명(Proof-of-Work) 합의 메커니즘에 필요하기 때문에 시간 개념을 가지고 있습니다. 유효한 타임스탬프가 없다면, 네트워크는 채굴되고 있는 특정 거래가 이전 거래를 조작하려 하는지 여부를 확인할 수 없습니다. 각 비트코인 블록이 UNIX 타임스탬프를 포함하고 있지만, 블록 시간은 UNIX 타임스탬프의 정확한 표현이 아닙니다. 이는 비트코인 합의가 타임스탬프를 실제 블록체인의 시간을 측정하는 도구가 아닌 PoW 보안 시스템의 일부로만 간주하기 때문입니다.

비트코인 위키에 따르면, 각 블록은 채굴자가 제공한 유닉스 시간 타임스탬프를 포함하며, 1) 이전 11개 블록의 중간 타임스탬프보다 크고 2) 네트워크 조정 시간에 2시간을 더한 값보다 작은 경우 유효한 것으로 받아들여집니다. 따라서 블록 시간과 실제 시간의 차이는 1시간에서 2시간 사이입니다.

출처: https://en.bitcoin.it/wiki/Block_timestamp

2. 이더리움

이더리움 네트워크에서도 타임스탬프는 채굴자들이 큰 유연성을 가지고 직접 제출합니다. 간단히 말해서, 이더리움 타임스탬프는 참일 수도 있고 거짓일 수도 있으며, 합의 메커니즘이 그 정확성을 확인할 방법이 없습니다. 이더리움 포럼의 게시물에 따르면(출처：https://ethereum.stackexchange.com/questions/413/can-a-contract-safely-rely-on-block-timestamp/428#428), 이더리움 타임스탬프의 과도한 편차를 방지하기 위해 여러 메커니즘을 사용할 수 있습니다: 1) 블록의 타임스탬프가 실제 시간과 크게 차이가 나면, 누구도 이 블록을 부모 블록으로 하여 더 많은 블록을 생성하려 하지 않을 것입니다; 2) 최신 블록의 타임스탬프는 부모 블록보다 이를 수 없습니다; 3) 블록이 필요한 것보다 이르게 표시되지 않을 때 블록 난이도가 가장 낮을 것입니다. 이러한 메커니즘은 채굴자들이 자발적으로 자신들이 정확하다고 믿는 타임스탬프를 제출할 수 있게 합니다. 하지만 다른 외부 인센티브가 존재할 때, 이더리움 네트워크는 채굴자들이 여전히 정확한 타임스탬프를 제출하도록 보장할 수 있는 엄격한 메커니즘이 없습니다. 따라서 네트워크는 시간에 민감한 프로토콜(예: 수익 농사, 대출)의 적절한 실행을 보장할 수 없습니다. 이러한 이유로 대형 기관들은 이더리움에 자금을 맡기지 않을 것입니다.

3. 폴카닷

서브스트레이트의 문서에 따르면, 폴카닷도 채굴자가 직접 제공하는 타임스탬프로 블록을 표시합니다. 한편, 이러한 타임스탬프를 확인하거나 동기화하는 엄격한 메커니즘은 없습니다. 문서는 또한 블록의 시간을 증명할 수는 없지만, 검증자들이 그것이 자신들의 시스템 시계와 어느 정도 델타 내에 있다는 것에 동의할 수 있다고 명시하고 있습니다.

출처: https://wiki.polkadot.network/docs/build-protocol-info

4. 코스모스

코스모스의 텐더민트는 합의 메커니즘에 시간을 기록하는 유일한 합의 알고리즘으로, 가장 강력한 시간 개념을 갖추고 있습니다. 구체적으로, 블록의 노드들은 제출된 시간에 대해 투표하여 합의에 도달하며, 노드들이 동의한 타임스탬프만이 블록에 포함됩니다.

출처: https://docs.tendermint.com/master/spec/consensus/bft-time.html

III. 블록의 타임스탬핑 시스템 부재

블록체인은 타임스탬프 생성에 있어 부정확할 뿐만 아니라, 블록 내에 타임스탬핑 시스템이나 메커니즘이 부족합니다. 현실 세계의 거래는 하나씩 전송되고 확인되며, 각각 명확한 시간과 순서를 가집니다. 이러한 방식으로 많은 허위 거래가 발생하거나 확인될 수 없습니다. 반면 블록체인 네트워크에서는 각 블록 내의 거래들이 함께 패키징되며, 개별적으로 정확한 타임스탬프가 표시되지 않습니다.

블록 생성 후 모든 거래를 검증할 수 있지만, 각 거래의 구체적인 제출 시간과 순서를 결정하는 것은 불가능합니다. 이는 많은 공격(예: 플래시 론이나 플래시 스왑)이 가능한 이유를 부분적으로 설명합니다. 블록 내에 검증을 위한 정확한 시간 표시가 제공된다면, 애플리케이션 프로토콜은 더 안전하고 안정적인 알고리즘을 개발할 수 있을 것입니다. 한편, 본질적 특성으로 인해 시간은 되돌릴 수 없고 변경할 수 없는 매우 안전한 합의 네트워크입니다.

IV. 잠재적 해결책

블록체인의 시간 부재는 내부적으로 또는 외부적으로 해결될 수 있습니다.

내부적 해결책: 블록 시간을 실제 시간과 대조하여 확인하는 합의 수준의 확인 메커니즘을 도입하거나, 더 높은 정확도를 가진 독립적인 시간 시스템을 구축해야 합니다.

외부적 해결책: 블록체인은 NTP와 유사한 시간 오라클 네트워크를 사용하여 네트워크 블록과 블록 내 거래에 정확한 타임스탬프를 추가하는 탈중앙화된 네트워크가 필요합니다.

멀티체인 협력의 관점에서 외부적 해결책이 더 적합할 수 있습니다. 예를 들어, 이더리움과 테라가 각각의 시계를 가지고 있다고 가정할 때, 이 시계들이 제공하는 타임스탬프가 다르다면 두 체인 간 상호작용 시 어느 것이 정확한지 판단하기 어려울 것입니다. 일반적인 컴퓨터 네트워크에서처럼 결국 하나의 마스터 시계가 모든 사람에게 시간을 알려주어야 합니다. 블록체인도 마스터 시계가 필요합니다.

미래의 멀티체인 기반 멀티버스에서는 또 다른 도전과제에 직면하게 될 것입니다 - 모든 다른 컴퓨터의 시계 수가 예상보다 훨씬 많다는 점입니다. 예를 들어, 게임 시계, DeFi 이자 발생 시계, 블록체인 시계 등이 있습니다. 이러한 시계들이 메타 노드의 시간을 교란시킬 수 있기 때문에, 모든 거래를 통합하고 동기화하기 위한 단일의 신뢰할 수 있는 시간 소스가 필요할 것입니다. 이러한 시간 오라클 네트워크가 결국 널리 채택되면, 실제 세계에서처럼 각 거래에 추가적인 시간 확인을 제공하는 추가 보안 계층을 제공할 것입니다. 시간은 또한 블록체인 네트워크의 추가적인 보안 계층이 될 것입니다.

참고문헌:

1. https://medium.com/@gokhansengun/bilgisayarlar-zaman%C4%B1-nas%C4%B1l-do%C4%9Fru-tutar-78c1203397f0
2. https://en.bitcoin.it/wiki/Block_timestamp
3. https://ethereum.stackexchange.com/questions/413/can-a-contract-safely-rely-on-block-timestamp/428#42
4. https://wiki.polkadot.network/docs/build-protocol-info