일반적으로 서로 다른 블록체인 네트워크를 연결하기 위해서는 아래와 그림과 같이 독립적인 브릿지 시스템이 필요하다.

이러한 브릿지 시스템 구조는 블록체인 네트워크와는 별개의 독립적인 시스템으로서 불가피하게 중앙화적 요소를 전체 시스템 내부로 포함시키게 한다. 일반적으로 블록체인 네트워크와 같은 탈중앙화된 분산 시스템에서는 단일 실패 지점이 존재하지 않는다. 특정 노드 또는 노드의 일부에 시스템 장애 또는 그에 준하는 문제 상황이 발생하더라도, 전체 네트워크 작동 여부에는 영향을 미치지 못한다. 즉 단일 실패 지점이 존재하지 않는다. 그러나 중앙화된 요소가 포함된 구조에서 아래와 같이 브릿지 시스템에 장애가 발생한다면, 두 블록체인 네트워크의 연결은 그 즉시 끊어지게 될 것이다. 즉 브릿지 시스템이 블록체인 연결의 단일 실패 지점이 된다.

BEATOZ는 Private Network(PrvNet) 와 Public Network (PubNet) 사이의 연결을 위한 브릿지 역할을 BEATOZ 네트워크를 구성하는 노드의 역할중 하나로 통합 하였다.
이를 통해 기존 브릿지 시스템 역할을 분산 시스템의 일부로 통합함으로서 중앙화 요소를 최소화 하였다. 따라서 PrvNet을 운영하는 팀은 별도의 브릿지 시스템 구축 없이, 브릿지 기능이 활성화된 BEATOZ 노드 운영 또는 이미 네트워크 상에 존재하는 공개 노드 활용을 통한 BEATOZ 네트워크 참여 만으로 두 네트워크 간의 원활한 커뮤니케이션 채널을 구축할 수 있다.

BEATOZ 연결 메커니즘의 장점

• 중앙화된 브릿지 제거
  별도의 브릿지 시스템이 필요 없어 보안성과 탈중앙성이 강화된다.
• 운영 비용 절감
  추가적인 브릿지 인프라 구축 및 운영 비용이 발생하지 않는다.
• 보안성 향상
  중앙화된 브릿지는 보안 취약점이 될 수 있지만, BEATOZ는 Node를 통해 직접 모니터링 및 트랜잭션 처리가 이루어지므로 보안성이 강화된다.
• 빠른 처리 속도
  중간 검증 절차 없이 직접 트랜잭션이 실행되므로 보다 빠른 트랜잭션 처리가 가능하다.
• 유연한 확장성
  프라이빗 블록체인의 확장과 연결이 간단해지며, 다양한 프라이빗 네트워크와의 상호 운용성이 증가한다.

통합된 브릿지 기능이 활성화된 BEATOZ Node 를 BEATOZ Linker Node (BLN) 라 한다.

모든 PrvNet은 자신을 PubNet과 이어주는 전용의 BLNs이 존재하여야 한다. 이는 PrvNet 운영팀이 BEATOZ PubNet에 노드 참여를 위해 운영해야 하는 BEATOZ Node의 일부로 구성될 수 있다. 다른 공개된 BLN을 사용할 수도 있지만, 시스템 가용성 측면에서 보안 취약성을 갖게 되기에 추천하지 않는다.

BLN은 PrvNet과 PubNet 사이의 커뮤니케이션 과정에서 핵심적인 역할을 수행한다. PrvNet 또는 PubNet의 트랜잭션 및 이벤트를 모니터링 하면서 중계 되어야 하는 트랜잭션이 발견되면, 해당 트랜잭션에 대한 검증 작업을 거쳐 타겟 네트워크로 이를 전파하는 역할이 그것이다.
BLN은 활성화된 브릿지 모듈을 통해서 연결하고자 하는 PrvNet과 PubNet 모두에 대한 모니터링을 수행한다. 그 중 어느 일방에서 중계가 필요한 트랜잭션이 발생하면 BLNs 는 각자 이에 대한 검증을 수행하고 그 결과와 트랜잭션 페이로드를 별개의 트랜잭션으로 생성하여 타겟 네트워크에 제출한다.
BLN에 의하여 타겟 네트워크에 제출된 트랜잭션은 BLN 각자가 자신의 서명으로 생성한 트랜잭션으로 원천 트랜잭션의 내용과 검증 결과를 포함하며, 타겟 네트워크의 트랜잭션 처리와 동일한 방법으로 전파되고 처리된다.

BEATOZ Linker는 특정 PrvNet 또는 PubNet (Source Chain)을 모니터링 하고, 여기서 트랜잭션이 발생하면 PubNet 또는 특정 PrvNet (Destination Chain)에 해당 내용이 전달 된다. Source Chain 과 Destination Chain 사이에 전달되는 메시지는 Source DApp 과 Destination DApp 정보를 포함하고 있으며, 결과적으로 Source Chain 에 발생한 트랜잭션의 내용은 메시지에 포함되어 Destination DApp 까지 전달 된다. 그리고 이렇게 전달된 데이터에 근거하여 Destination DApp 은 필요한 작업을 수행할 수 있다.

Listener는 하나의 네트워크(체인)에서 또 다른 체인으로 전달할 트랜잭션을 이벤트 모니터링을 통해 감지한다. 이벤트가 수신되면 RPC 기능를 이용하여 해당 트랜잭션을 조회 한다.
트랜잭션 조회를 통해 이벤트의 진위 여부가 확인되면, 메시지 전달 경로를 나타내는 라우팅 정보, 트랜잭션의 내용을 담은 트랜잭션 페이로드와 이에 대한 BLN의 서명으로 전달한 메시지를 구성하고 이를 Transporter로 전달 한다.
Transporter 로 전달되는 메시지는 다음과 같은 내용을 담고 있다.

• SrcChainID
  Tx0가 발생한 소스 체인 ID.
• SrcAppID
  Tx0를 처리한 소스 DApp ID. (e.g. 컨트랙트 주소 또는 체인코드 ID.)
• DstChainID
  Tx0을 전달할 타겟 체인 ID.
• DstAppID
  Tx0을 전달할 타겟 DApp ID. (e.g. 컨트랙트 주소 또는 체인코드 ID.)
• Tx0Payload
  Tx0의 내용을 인코딩한 데이터
• BLNSig
  BLN의 서명.

Transporter는 BEATOZ의 브릿지 기능을 담당하는 핵심 모듈인 BEATOZ Linker의 하위 모듈이다. 이 모듈은 블록체인 간 안전하고 신뢰성 있는 메시지 전송을 담당하며, 전송되는 데이터의 신뢰성과 무결성을 유지하는 역할을 한다. Transporter는 검열 저항성(Censorship Resistance)과 중복 전송 방지(No Replay)를 구현하여, 네트워크의 보안성과 안정성을 강화한다.

Censorship Resistance (검열 저항성)

블록체인 브릿지 기술에서 Censorship Resistance(검열 저항성) 은 특정 엔터티나 중간 노드가 임의로 메시지를 차단하거나 지연시키지 못하도록 보장하는 중요한 속성이다. 이는 블록체인 네트워크의 탈중앙성과 신뢰성을 유지하는 핵심 요소로 작용한다.

• 탈중앙성 유지

  중앙화된 브릿지 시스템은 특정 기관이나 노드가 메시지를 검열할 가능성을 내포한다. 이를 방지하지 않으면 네트워크의 본질적인 탈중앙성이 훼손될 수 있다.

• 신뢰할 수 없는 환경에서의 보장

  블록체인은 본질적으로 신뢰할 수 없는 환경에서 작동하는 시스템이므로, 특정 노드나 참여자가 메시지를 검열할 가능성을 배제해야 한다.

• 트랜잭션의 무결성 유지

  검열이 가능해지면 메시지가 임의로 누락되거나 지연될 수 있으며, 이는 블록체인 네트워크의 신뢰성을 약화시킨다.

• 자산 이동의 자유 보장

  블록체인 브릿지는 퍼블릭 및 프라이빗 블록체인 간의 자산과 데이터 이동을 담당하며, 특정 트랜잭션이 의도적으로 차단될 경우 네트워크의 기능성이 제한될 수 있다.

No Replay (중복 전달 방지)

Replay(중복전달)은 네트워크에서 이전에 발생한 트랜잭션을 재전송하여 동일한 작업이 여러 번 실행되도록 하는 공격 방법이다. 블록체인 환경에서는 공격자가 이미 승인된 트랜잭션을 다시 네트워크에 제출하여 중복 실행을 유도할 수 있다. 예를 들어, 사용자가 A에게 10개의 토큰을 전송한 트랜잭션을 공격자가 다시 제출하면, 동일한 금액이 다시 A에게 전송되는 문제가 발생할 수 있다.

• 사용자 자산 보호

  동일한 트랜잭션을 담은 메시지가 여러 번 전달, 실행되면 사용자 자산이 의도하지 않게 소진될 수 있기에 동일한 메시지의 전달이 불가능해야 한다.

• 네트워크 무결성 유지

  중복된 메시지의 전달이 허용되면, 데이터 정합성 및 신뢰성이 저하된다.

• 보안 강화

  공격자가 동일한 트랜잭션을 재전송하여 시스템을 악용하는 행위를 방지할 수 있다.

Transporter는 신뢰성 있는 메시지 전달을 위해, Listener로 부터 수신한 각 메시지에 순차적으로 증가하는 정수값 nonce를 부여하고 이를 관리한다.
여기서 nonce가 부여된 메시지는 Verifier 의해 최종 사용자 DApp 으로 전달 될 때, 반드시 그 순서대로 전달 될 것이 보장된다. 이는 nonce n이 부여된 메시지 M_n은 반드시 M_n+1 보다 앞서 전달 되어야 함을 의미한다. 만약 M_n이 전달되지 않았다면 M_n+1를 포함하여 그 이후 모든 메시지는 최종 사용자 DApp으로 전달 될 수 없다.

이로서 메시지가 임의로 차단되거나 재정렬되지 않도록 보장(Censorship resistance) 하고, 이전에 처리된 메시지(동일한 nonce) 가 다시 제출될 경우, 이를 자동으로 무효화 함으로서 동일한 메시지가 중복 전달 되지 않도록 한다. (No Replay)
여기서 nonce의 순차적 증가는 전체 메시지에 대하여 순차적인 증가가 아니라, 전달 채널의 양 종단을 구성하는 두개의 DApp pair별로 독립적인 증가를 의미한다. 즉 DApp1 과 DApp2 사이의 nonce 와 DApp1 과 DApp3 사이의 nonce는 독립적으로 증가되는 별개의 nonce가 되어야 한다.

Transporter는 최종적으로 구성 완료된 메시지의 해시와 BLN 서명을 Verifier 에게 전달 하고, 이후 Verifier는 해당 메시지 전달건에 대한 BLNs 합의 여부를 확인한다. 합의가 확인되면 해당 메시지 해시값이 다시 Transporter로 전달 된다. Transporter는 Verifier로부터 BLNs 합의가 확인된 메시지의 해시값을 전달받은 후, 이를 DApp으로 전달함으로써 메시지 전달을 완료한다.

그러나 Verifier에 의해 확인되는 합의의 순서는 반드시 메시지의 순서(nonce 순서)와 일치하지 않을 수 있다. 때문에 Transporter는 마지막으로 해당 DApp으로 전달한 메시지 nonce(lastDeliveredNonce)를 기준으로, 연속된 nonce를 유지하면서 메시지를 전달하는 기능을 구현한다.

예를 들어, lastDeliveredNonce가 100인 상태에서 nonce 값이 102, 103, 104, 106인 메시지 M₁₀₂, M₁₀₃, M₁₀₄, M₁₀₆ 에 대하여 Verifier로부터 합의 확인을 받았다고 할 때, 이 메시지들에 대한 합의가 확인되었음에도 불구하고, DApp으로 전달은 보류되어야 한다. 그 이유는 메시지 M₁₀₁에 대한 합의가 아직 Verifier로 부터 확인되지 못했기 때문이다. Transporter는 M₁₀₁이 Verifier에 의해 합의 확인되면, M₁₀₁, M₁₀₂, M₁₀₃, M₁₀₄를 순차적으로 DApp에 전달한다. 반면, M₁₀₆은 여전히 M₁₀₅가 도착하기 전까지 보류된다. 이 와 같이 연속된 nonce 순서를 유지해야만 메시지가 DApp으로 전달되며, 이 과정이 보장되지 않으면 메시지의 순서(실행 순서)가 노드 마다 달라지게 되고 그렇게 되면 블록체인 데이터의 무결성이 훼손될 수 있다.

BEATOZ의 Linker 모듈에는 Verifier라는 하위 모듈이 존재하며, 이는 메시지 전달의 신뢰성을 보장하는 핵심 역할을 수행한다. Verifier는 BEATOZ Linker Node(BLN)들이 특정 메시지 전달에 대해 합의 여부를 확인하고, 합의 여부가 확인 되는 시점에서 이를 다시 Transporter 로 알린다.

Verifier의 가장 중요한 역할 중 하나는 BLN 간의 합의 여부를 검증하는 것이다. BEATOZ 네트워크에서 특정 트랜잭션이 수행될 때, 단일 노드가 임의로 트랜잭션을 승인하는 것이 아니라 여러 BLN들이 함께 참여하여 합의해야 한다. Verifier는 각 BLN이 제출한 정보를 수집하고, 일정 기준을 충족하는지 확인하여 메시지의 신뢰성을 평가한다. 이를 통해 특정 노드가 악의적인 행위를 하더라도 트랜잭션이 무결하게 유지될 수 있도록 한다.

이러한 합의 기준을 정의하고 유지하는 것이 Security Policy이다. Verifier는 Security Policy를 관리하며, 해당 정책은 특정 DApp의 owner에 의해서만 정의되고 업데이트될 수 있다. Security Policy는 BLN 간의 합의 조건을 명확히 규정하며, 메시지가 네트워크에서 유효하게 처리되기 위해 필요한 최소 요건을 설정한다.

Verifier는 Transporter 모듈과 긴밀하게 연동된다. Transporter는 메시지의 전달을 담당하는 모듈로, 특정 트랜잭션이 발생하면 Verifier에게 해당 트랜잭션의 해시값과 현재 실행 중인 트랜잭션의 발생시킨 BLN 정보를 전달한다. Verifier는 이를 저장하고 Security Policy 기준에 따라 검토한 후, 조건을 충족하는 경우 해당 메시지의 해시값을 다시 Transporter로 전달한다. 이 과정을 통해 최종적으로 검증된 메시지만이 BEATOZ 네트워크에서 실행될 수 있도록 보장된다.

Verifier는 네트워크의 보안성과 무결성을 유지하는 데 핵심적인 역할을 수행한다. 중앙화된 검증 시스템이 없이도, BLN 간의 분산된 합의를 통해 신뢰할 수 있는 메시지 검증이 가능해진다. 또한, 악의적인 BLN이 허위 정보를 제출하거나 특정 트랜잭션을 조작하려는 시도를 차단할 수 있으며, 네트워크 전반에 걸쳐 트랜잭션의 신뢰성을 향상시킨다. 이러한 설계를 통해 BEATOZ는 블록체인 간의 데이터 전송을 보다 안전하고 효율적으로 수행 할 수 있다.

Security Policy

Security Policy는 BEATOZ 네트워크에서 BLN(BEATOZ Linker Node)들의 최소 합의 조건을 정의하는 정책이다. 이는 메시지 전달의 보안성과 신뢰성을 높이는 중요한 역할을 하며, 블록체인 간 트랜잭션이 올바르게 수행되도록 보장한다. Security Policy는 DApp의 owner에 의해 직접 설정 및 업데이트될 수 있으며, 네트워크 전체에서 적용되는 정적인 합의 조건이 아니라, 각 DApp이 원하는 방식으로 유연하게 정의할 수 있다. 즉, BEATOZ에서는 고정된 합의 조건을 강제하는 것이 아니라, 개별 DApp이 자신의 요구사항에 맞는 검증 기준을 설정할 수 있도록 지원한다.

Security Policy는 다음과 같은 주요 정보를 포함한다.

• OwnerID

  Security Policy의 소유자로, 해당 정책을 설정하고 변경할 수 있는 권한을 가진 DApp의 owner를 의미한다.

• RequiredBLNs

  반드시 합의에 참여해야 하는 BLN들의 목록이다. 이 목록에 포함되지 않은 BLN이 아무리 많은 메시지 전달에 동의하더라도, RequiredBLNs에 속한 노드들이 동의하지 않으면 해당 메시지 전달은 합의되지 않은 것으로 간주된다.

• OptionalBLNs

  합의에 참여해도 되고 하지 않아도 되는 BLN들의 목록이다. 이 목록에 포함된 노드들은 RequiredBLNs 조건을 충족하는 범위 내에서 자유롭게 합의에 기여할 수 있다.

• RequiredBLNCount

  특정 메시지 전달이 유효하게 합의되기 위해 필요한 최소 BLN 수를 의미한다. 최소 이 수만큼의 BLN이 동의해야 해당 메시지는 합의된 것으로 간주된다.
  즉, len(RequiredBLNs) + len(OptionalBLNs) >= RequiredBLNCount 조건이 만족되어야 한다.

이러한 Security Policy를 통해 BEATOZ 네트워크는 탈중앙성과 보안성을 동시에 확보할 수 있다. 중앙화된 검증 시스템 없이도, 각 DApp이 원하는 보안 수준에 따라 독립적으로 합의 정책을 설정할 수 있으며, 이를 통해 보다 유연하고 안전한 블록체인 간 메시지 전달이 가능해진다.