# 3.3 Zytron Kit

## 3.3.1 Sovereign Rollup for Data

3.3.1.1 Sequencer

Sequencer는 Layer2 시스템에서 거래 순서를 결정하는 중요한 구성 요소로, 전체 시스템의 진입점인 첫 번째 구성 요소입니다. Sequencer는 메모리 풀에 있는 거래를 정렬하고 Layer2 블록을 형성하기 위해 패키징합니다. 그리고 Layer2 블록을 순서대로 Batch로 패키징합니다. 이후의 거래 실행, 거래 처리 등의 기능은 모두 Sequencer가 생성한 블록 순서에 따라 실행됩니다.

사용자가 Zytron에 전송한 거래는 Sequencer에 의해 우선적으로 정렬되어 전역 순서를 결정합니다. 이 순서의 결정은 분산 정렬기에 의해 이루어집니다. 분산 정렬기는 거래 정렬 및 기본 거래 서명 검증 작업만 수행하며, 구체적인 거래를 실행하지 않으며 스마트 계약을 실행하지도 않습니다. 이는 Sequencer가 완전한 거래 영수증을 패키징할 수 없음을 의미하며, 단지 거래의 정렬을 구성하여 Zytron의 거래 분할 서비스가 완료하도록 Batch를 전달합니다.

구체적인 패키징 프로세스는 다음과 같습니다:

1. Sequencer의 각 노드는 P2P를 수행하지 않는 메모리 풀을 사용하며, 이 노드에 전송된 거래는 로컬에서만 패키징됩니다. Sequencer 노드는 정해진 시간마다 거래를 패키징하여 거래 블록을 형성합니다.

2. 해당 거래 블록 내의 거래는 Merkle 트리로 구성됩니다. Merkle의 루트는 Sequencer의 P2P 네트워크에서 브로드캐스트됩니다. 이 브로드캐스트 과정에서는 Merkle 루트만 브로드캐스트하면 되며, 전체 거래 본체를 브로드캐스트할 필요는 없습니다. 거래 블록 내의 서명을 집계하여 검증함으로써 데이터 양을 더욱 줄였습니다.

3. Sequencer가 패키징한 거래 블록의 구체적인 데이터는 외부 DA에 제출됩니다. DA 내의 확인 주기가 너무 길어져 지연되는 것을 방지하기 위해, Sequencer는 데이터를 임시로 "약한" DA에 제출합니다.

4. Sequencer가 생성한 거래 블록은 Sequencer의 PBFT 합의에 의해 추가로 Batch로 패키징됩니다. 이 Batch는 이후 서비스 분할에서 구체적인 거래 계약 실행을 위해 최종 제출됩니다.

3.3.1.2 External DA

Zytron에서는 "강한" DA와 "약한" DA의 두 가지 DA를 사용합니다. 이른바 "약한" DA는 Sequencer가 거래 블록을 패키징할 때 거래 블록의 데이터를 기록하는 데 사용됩니다. 이 DA는 합의 지원을 요구하지 않으며, 단지 Sequencer 네트워크의 노드에 구체적인 거래 블록 정보를 신속하게 전달하기 위해 존재합니다. 이와 같은 DA는 공개 접근이 가능한 서버, s3 등의 중앙화된 서비스를 직접 사용할 수 있습니다. 이 "약한" DA는 Zytron의 "파이프라인"식 거래 실행 최적화 전략을 주로 지원합니다.

"강한" DA에 기록된 것은 Sequencer가 패키징한 Batch 데이터입니다. 이 데이터는 형성된 후 최종 계약 실행의 입력으로 사용됩니다. 따라서 이 거래의 데이터는 접근성이 높은 시스템에 배치되어야 합니다. 이와 같은 데이터는 데이터의 접근성을 강조하며, 종종 데이터 제출 주기가 길어지게 됩니다. 따라서 강한 DA의 데이터는 주로 고정된 시점 이전에 체인 상 데이터 실행 결과의 검증에 더 많이 사용됩니다.

강한 DA와 약한 DA의 차이는 다음과 같습니다:

DA와 Sequencer의 상호작용 프로세스에서, Sequencer 간에는 P2P를 통해 능동적으로 데이터를 브로드캐스트하는 방식이 사용됩니다. 이러한 데이터 브로드캐스트는 합의 전에 데이터를 신속하게 브로드캐스트하여 거래 처리 지연을 줄이기 위한 것입니다. 구체적인 거래 데이터는 Sequencer가 해당 노드에서 능동적으로 추출해야 합니다.

3.3.1.3 Sequencer Pending State

게임 진행 중에는 대량의 거래가 네트워크에 빈번하게 전송됩니다. 게임의 낮은 지연성 요구로 인해 거래 실행 결과가 체인에서 확인된 후에야 사용자에게 반환되기를 기다리는 것은 사용자 게임 경험의 급격한 저하를 초래합니다. 따라서 사용자가 거래를 Sequencer에 전송할 때, Sequencer는 로컬에서 Pending State를 유지하며, 사용자는 자신이 연결된 Sequencer 거래 노드를 기반으로 Pending 상태를 지속적으로 가져올 수 있고, 거래가 최종적으로 확인되기 전에 새로운 거래를 미리 발송할 수 있습니다. Sequencer에 기록된 Pending State는 체인 상의 최종 상태와 지속적으로 동기화되어 자신의 Pending State를 수정하는 데 사용됩니다.

## 3.3.2 ZK Rollup for Assets

자산은 데이터와 다르며, 자산은 매우 뚜렷한 가치 속성을 가지고 있으며 유동성이 필요합니다. 따라서 Layer3의 자산은 별도로 처리해야 하며, 자산의 안전성을 더 안전한 Layer1/Layer2에 의존해야 합니다. 이를 위해 우리는 zk rollup 기반의 자산 관리 솔루션을 설계하여 Zytron Kit에서 발행된 Layer3에 적용합니다.

zk-Rollups를 사용한 자산 관리:

L3 자산 거래:

Merkle 트리 저장: 우리는 L3에서 발생한 자산 거래와 L1/L2 소스 체인에서 발생한 입금 및 출금 거래를 모두 하나의 Merkle 트리에 저장합니다. 이 Merkle 트리의 각 분기는 3개의 leaf를 가지며, 각 leaf는 하나의 output을 나타냅니다.

• UTXO 모델: UTXO 모델의 전송 알고리즘을 채택하여 모든 거래의 유효성 검사를 zk 집계로 촉진하여 L1/L2에서 즉시 검증할 수 있습니다. op와 같이 7일의 도전 기간이 필요하지 않습니다.

거래 유형 및 프로세스:

• Deposit: 소스 체인에 존재하므로 서명을 회로에 기록할 필요가 없으며, 이는 완전히 공개된 public inputs입니다.

• Transfer: inputs와 outputs의 거래 유효성을 제출하고, 회로에 사용자 서명을 삽입하여 거래를 검증합니다. L3 전송 거래는 필드 친화적인 서명 알고리즘을 사용하여 회로 내에서 효율적인 증명을 달성합니다.

• Withdraw: Transfer 알고리즘과 동일하게 처리되지만, 해당 output의 수신자는 소스 체인에 해당하는 계정 형식으로 지정되며, Merkle 트리의 증명에 참여할 수 있으며, 더 이상 어떤 input에서도 사용될 수 없습니다.

회로 구동 거래 유효성:

• Leaf 증명 및 Merkle Root 업데이트: Leaf의 변화는 Merkle Root의 업데이트를 초래합니다. 이러한 변경의 유효성은 회로에서 증명되어 Merkle Root 업데이트에 필요한 체인 상 계산을 줄입니다.

• 소스 체인에 제출된 public inputs: 입금 및 해당 output, 전송과 관련된 inputs 및 outputs, 출금에서 발생한 inputs 및 특별 outputs, 그리고 최종 Merkle 트리 루트 등 모든 자산 거래의 유효성은 ZKP를 통해 증명됩니다.

UTXO 구조:

• 자산 유형 및 금액: 두 가지 모두 u256 유형으로, ERC20 토큰 유형 및 ERC721 NFT 유형을 처리할 수 있습니다.

• 소스 체인 상의 계약 매핑: 소스 체인 계약에서 해당 매핑 관계를 잘 설정하면 자산을 L3로 브리징할 수 있으며, 자산의 안전 가정을 소스 체인에 기반하여 L3의 안전성 의존도를 줄일 수 있습니다.

• 실행 계획에는 ZK inputs 및 outputs로 처리되는 UTXO 거래, 구형 Merkle 루트에서 신형 Merkle 루트로의 전환, 자산 유형 및 금액과 토큰 및 NFT 유형과의 관련 매핑 테이블 및 매핑 관계를 직관적으로 설명하는 차트 생성이 포함됩니다. 이러한 구조적 접근 방식은 기본 블록체인 계층의 보안 기능을 활용하여 L3 자산 관리의 이해 및 투명성을 강화합니다.

## 3.3.3 서비스 분할

Zytron의 설계 목적은 낮은 지연의 체인 상 게임 서비스를 구현하는 것이므로, 이를 달성하기 위해 Zytron에서 실행되는 계약은 체인 노드의 데이터 서비스를 분할하여 실행됩니다.

3.3.3.1 Kademlia 알고리즘 기반의 노드 데이터 분할

Kademlia는 분산 해시 테이블 알고리즘으로, 노드 ID의 XOR 연산을 사용하여 네트워크 내의 노드 거리를 측정합니다. 이 거리의 규정을 활용하여 노드 분할 계산 및 네트워크 내 노드 발견 등의 기능을 기준으로 삼을 수 있습니다. 원래 Kademlia는 P2P 네트워크의 데이터 저장 및 노드 발견 솔루션을 위해 설계되었습니다. Zytron에서는 Kademlia 알고리즘의 노드 규칙을 활용하여 계산만으로 서비스 분할을 완료하고 시스템 내 네트워크 요청 수를 줄입니다.

Zytron은 구체적인 계약 검증을 실행하는 노드를 P2P 네트워크를 통해 연결합니다. 노드 간의 주소 지정은 구조화된 Kademlia 알고리즘을 통해 완료됩니다. 동시에 네트워크 내 계약의 실행 과정도 Kademlia의 노드 거리 기준에 따라 분할되어 지정된 계약의 실행이 Zytron 네트워크의 실행 노드에 분산되어 수행됩니다. Zytron의 실행 노드가 되기 위해서는 다음과 같은 프로세스를 완료해야 합니다:

• Zytron의 각 실행 노드는 Sequencer에서 전송된 거래 블록을 수신할 수 있으며, Zytron이 의존하는 상위 블록체인에서 합의된 Batch를 읽고 DA에서 구체적인 Batch 데이터를 읽습니다.

• 노드는 자신의 개인 키를 사용하여 160비트 노드 ID를 생성합니다.

• 각 노드는 상위 블록체인에 등록해야 하며, 등록 후 상위 블록체인의 계약이 현재 노드의 ID를 기록합니다.

• 노드가 네트워크에 가입한 후 P2P 프로토콜을 통해 자신의 조회 작업을 시작하여 관련 이웃의 라우팅 테이블에 업데이트될 수 있도록 합니다.

• 주변 노드에 상태 데이터 동기화 요청을 보냅니다.

• 동기화가 완료된 후 상위 블록체인에 동기화 성공 결과(자신이 기록한 데이터 상태의 Merkle Root)를 등록합니다.

노드가 실행 노드가 된 후, 노드는 주변 데이터에 상태 데이터 동기화 요청을 시작하며, 이 데이터 동기화 요청은 주변 노드 중 계정 주소가 자신의 노드 ID와 가장 가까운 관련 데이터, 잔액, nonce 등을 자신의 저장소로 동기화합니다.

3.3.3.2 주소 상태 그룹

Zytron의 실행 노드는 전체 상태를 기록하지 않으며, 각 실행 노드는 자신과 가장 가까운 주소와 관련된 저장 정보를 기록합니다. 노드가 오프라인 상태가 되어도 실행 노드가 거래를 정상적으로 검증할 수 있도록 하기 위해, 실행 노드는 매번 가장 가까운 주소에서 동기화된 저장 데이터를 가져올 때마다 주소 상태 그룹에 추가하거나 생성합니다. 각 주소 상태 그룹에는 8명의 구성원이 있으며, 이들은 BFT 알고리즘을 사용하여 로컬에서 주소의 상태를 업데이트합니다.

주소 상태 그룹 초기화 알고리즘:

거래가 Zytron 노드에서 실행되면, 주소 상태 그룹은 거래 기록의 Address Space를 기반으로 여러 주소 상태 그룹을 결합하여 스마트 계약을 실행하고 이 거래의 상태를 업데이트하여 거래 상태를 갱신합니다. 또한 Zytron은 Address Space Access List 및 Key Space Access List와 같은 기능을 갖추고 있어, 계약 실행 전에 주소 상태 그룹의 병합을 완료할 수 있으며, 계약 실행 후에 병합을 기다릴 필요가 없습니다.

어떤 노드가 오프라인 상태가 되면, 관련 주소 노드 그룹은 해당 노드를 제외하고 상위 블록체인에 이 퇴출 행동을 기록합니다.

3.3.3.3 거래 Space Access List 필드

Zytron에서 노드의 데이터가 분할 저장되기 때문에 실행 노드에는 완전한 전체 상태가 존재하지 않습니다. 거래 실행 과정에서 주소 상태 그룹이 거래를 공동으로 실행하더라도, 동적으로 연결을 계속 추가하거나 거래를 실행하는 등의 작업이 매우 어렵습니다. 따라서 데이터가 정상적으로 분할 처리 계산될 수 있도록 거래가 체인에 전송될 때, 이 거래가 업데이트할 State Change 정보를 추가해야 하며, 이 정보는 Space Access Limit이라고 불립니다. 이 정보에는 거래가 변경할 잔액, Nonce, Storage 정보가 포함됩니다. 노드는 거래를 수신한 후 Space Access Limit에 따라 노드 로컬에서 계약 실행 조건을 충족하는 상태를 거래 "to" 주소가 위치한 주소 상태 그룹 노드에 배치합니다. 노드 실행 과정에서 접근하는 데이터가 Space Access List에 기록된 데이터 범위를 초과하거나 그 상태 변화와 차이가 발견되면 거래 실패로 판단됩니다.

각 Batch 실행이 끝난 후, 주소 상태 그룹은 상위 체인에 State Root와 관련된 zkproof 또는 Fraud Proof를 제출합니다.

3.3.3.4 Key Space 추정

대부분의 EVM 클래스 또는 전체 상태 클래스 계약 실행 엔진은 기본적으로 Space Access List 필드가 존재하지 않으며, 스마트 계약 실행이 끝나기 전에는 아무도 거래의 실행 상태를 알 수 없습니다. 따라서 클라이언트가 이 필드를 정상적으로 표시할 수 있도록 Zytron은 Space Access Limit 추정 기능을 제공합니다. 이 기능은 전송된 거래를 기반으로 지정된 상태에서 스마트 계약을 실행하고, 계약 실행 과정에서 접근한 데이터와 생성된 데이터를 기반으로 Space Access Limit을 구성합니다.

## 3.3.4 맞춤형 네트워크

현재 블록체인의 기본 P2P 네트워크는 많은 프로젝트가 libp2p 또는 사용자 정의 라이브러리를 기반으로 하고 있으며, 이러한 라이브러리는 블록체인에 기반하여 생성되며, 가장 중요한 특징은 블록과 거래를 빠르게 전파하는 것입니다. 따라서 broadcast 알고리즘, 예를 들어 gossip 알고리즘에 특히 주목합니다. 이는 메시지가 짧은 시간 내에 전체 네트워크에 브로드캐스트될 수 있도록 보장합니다. 그러나 게임의 시나리오는 제한된 노드 간의 메시지 전송으로, 심지어 두 개의 노드만 관련되며, 이 연결이 안정적이고 효율적이어야 하며, 임의로 끊기지 않거나 끊어진 후에도 신속하게 복구될 수 있어야 합니다. 그러나 블록체인의 P2P 라이브러리는 이러한 특징을 갖추고 있지 않습니다. 따라서 우리는 P2P 네트워크 라이브러리에 대해 맞춤형 개발을 진행했습니다.

먼저 네트워크 전송 프로토콜에 대해, 고빈도 작업의 게임에서는 네트워크 지연을 극도로 낮춰야 합니다. 예를 들어 60프레임의 게임이라면, 매초 60번 업데이트해야 하므로 지연은 16ms 이하로 유지되어야 프레임 드롭 없이 끊김을 피할 수 있습니다. 이를 위해 우리는 클라이언트 성능을 최적화할 뿐만 아니라 대부분의 시간을 차지하는 네트워크 전송도 최적화해야 합니다. 전통적인 P2P 네트워크는 일반적으로 TCP 전송 프로토콜을 사용하지만, TCP는 신뢰할 수 있는 재전송을 포함하고 있으며 혼잡 메커니즘이 있습니다. 네트워크에서 트래픽이 많으면 TCP의 전송 시간이 연장되어 게임의 요구를 충족할 수 없습니다. 따라서 우리는 KCP 전송 프로토콜을 기반으로 한 p2p 네트워크 라이브러리를 수정했습니다. KCP는 UDP를 기반으로 구현된 빠르고 신뢰할 수 있는 프로토콜로, TCP보다 10%-20%의 대역폭을 낭비하는 대가로 평균 지연을 30%-40% 줄이고 최대 지연을 세 배로 줄이는 전송 효과를 제공합니다. KCP는 순수 알고리즘 구현으로, 기본 프로토콜(예: UDP)의 송수신을 담당하지 않으며, 사용자가 하위 데이터의 전송 방식을 정의해야 하며, callback 방식으로 KCP에 제공해야 합니다. 심지어 시계도 외부에서 전달되어야 하며, 내부에서는 어떤 시스템 호출도 없습니다.

노드 연결의 안정성을 보장하기 위해, 우리는 P2P 핵심 주소 지정 알고리즘을 최적화하여 이중 DHT 기반의 안정적인 P2P 네트워크 구조를 채택했습니다. 한 층은 노드의 peer id를 사용하여 처음 160비트의 XOR 거리에서 Kademlia 알고리즘을 수행하고, 해당 DHT의 버킷을 8로 유지하여 네트워크의 연결 및 변동에 충분히 대응하며, stable kademlia를 사용하여 네트워크 노드의 출입으로 인한 테이블 변동을 유지합니다. 다른 층은 소켓 IP 주소의 거리 알고리즘을 사용하여 IP를 통해 물리적 위치의 근접성을 측정합니다. 이 방법의 장점은 두 노드가 직접 연결할 수 없는 경우, 예를 들어 둘 다 로컬 네트워크에 존재하고 ISP 장치가 Port-Restricted Cone 또는 Symmetric인 경우 NAT 및 hole punching을 통해 직접 연결을 시도할 수 없을 때, relay 알고리즘을 사용하여 세 번째 노드를 통해 안정적인 연결을 실현할 수 있다는 것입니다. 이때 세 번째 노드는 두 노드와 물리적 거리가 너무 멀지 않아야 하며, 전송 효율성을 높이고 시간을 줄이는 데 기여해야 합니다.

## 3.3.5 Zytron chain

3.3.5.1 Web3 호환 인터페이스

Zytron은 거래 지연을 줄이기 위해 다양한 최적화 기술을 사용하지만, 이러한 최적화 기술로 인해 체인의 인터페이스와 데이터 형식이 원래 Web3 인터페이스와 큰 차이를 보입니다. 따라서 개발자에게 일관된 사용자 경험을 보장하기 위해 Zytron은 두 가지 인터페이스를 제공합니다. 첫 번째는 Zytron 전용 인터페이스로, Zytron의 최적화 기술을 잘 활용하여 더 낮은 거래 지연을 얻을 수 있습니다. 개발자 생태계의 일관성을 보장하기 위해 Zytron은 Web3 호환 인터페이스도 제공하며, 이 인터페이스에서는 Web3 인터페이스의 Pending State를 Pending 관련 쿼리로 변환하고, 독립적인 Web3 호환 인터페이스가 데이터 주소 지정, 거래 Space Access List 추정 등의 작업을 담당합니다.

3.3.5.2 다중 실행 엔진 지원

Zytron은 본질적으로 거래 실행 엔진으로, 거래 실행의 지연을 줄이고 네트워크의 TPS를 증가시키기 위해 설계되었습니다. 그러나 설계에서 계약 실행 엔진의 종류를 제한하지 않았으며, 현재 설계에서는 UTXO 거래 모델과 EVM 계약 엔진을 사용할 수 있습니다. 더 많은 요구가 도입됨에 따라 Zytron은 다양한 응용 시나리오를 실현하기 위해 더 많은 실행 엔진에 개입할 수 있습니다. 심지어 요구에 따라 Zytron의 서로 다른 주소 상태 그룹은 서로 다른 실행 엔진을 사용할 수 있습니다. 예를 들어, Zytron의 토큰을 사용하면 UTXO 모드를 활용하여 거래 동시 실행 시 발생할 수 있는 문제를 피할 수 있으며, 구체적인 계약 거래는 EVM 모델을 사용하여 gas 정산 시 거래 의존 문제 등을 피할 수 있습니다.

3.3.5.3 Zero Gas

ERC4337은 이더리움 표준으로, 기존 Layer1 인프라를 수정하지 않고 "계정 추상화 지갑"을 생성할 수 있는 방법을 제안합니다. 이러한 지갑의 거래는 누구나 블록체인에 전송할 수 있으며, 수수료는 제3자가 지불할 수 있습니다. 이는 사용자가 거래 수수료를 ETH로 지불하거나 대납할 필요 없이 거래를 실행할 수 있음을 의미합니다.

Zytron은 EIP4337의 계정 추상화 지갑을 기본적으로 지원하며, 계정 추상화 지갑을 활용하여 Zytron은 규칙에 부합하는 계정에 거래 수수료 면제 기능을 제공합니다. 이 기능은 Sequencer가 거래 수신 시 직접 변환하여 0gas 서비스 기능을 실현합니다.

3.3.5.4 Cross-chain Bridge

Zytron의 분할 실행 모드는 체인과 상위 블록체인이 특정 주소 상태 그룹에 연결될 수 있도록 합니다. 따라서 이 특별한 주소 상태 그룹에서 Zytron은 특별한 입금 거래를 지원합니다. 이 거래는 상위 블록체인에서 파생된 것으로, 상위 블록체인에서 잠금된 Token을 Zytron에서 mint할 수 있도록 합니다.