원출처: 엠버그룹
첫 번째 레벨 제목
"DAG"는 정확히 무엇을 의미합니까?
"DAG"는 "Directed Acyclic Graph"의 약어입니다. 컴퓨터 과학에 익숙하지 않은 사람들에게는 용어가 많을 수 있으므로 다음과 같이 각 단어를 자세히 설명합니다.
- Directed: 이 데이터 구조의 데이터는 한 방향으로만 전송됩니다.
- 비주기적(acyclic) : 데이터 구조상 현재 상태에서 이전 상태로의 복귀가 불가능, 즉 "비주기적"
- 그래프: 데이터 구조 시각화에서 구조는 여러 꼭짓점 간의 상호 연관된 관계 집합으로 표시됩니다.
DAG 구조는 정확히 어떻게 생겼습니까? 데이터 정렬 방법을 확인하는 것이 데이터 구조가 DAG인지 블록체인인지 확인하는 가장 좋은 방법입니다. 이 정렬 방법은 거래가 적시에 정렬되는 방식을 나타냅니다. 우리는 시간이 선형이라는 것을 이해하기 때문에 종종 사건이 특정 순서로 발생한다고 생각합니다. 인간은 시간 개념에 동의하므로 사건이 순차적으로 발생한다는 데 동의합니다.
위의 그림은 "전체 시퀀스"의 예입니다. 어떤 이벤트가 먼저 발생하는지 결정되면 모든 이벤트는 정확한 순서를 갖게 됩니다. 이벤트의 전체 순서에서 각 이벤트가 전체 순서의 어디에 있는지 정확히 알고 있습니다. 그림과 같이 전체 순서를 사용하면 이벤트 A가 먼저 발생하고 이벤트 B, 이벤트 C가 차례로 발생합니다. 이것이 이벤트가 블록체인에 기록되는 방식입니다.
그러나 분산 원장의 전체 순서는 처리량 및 대기 시간 측면에서 확장성을 제한할 수 있습니다. 문제의 일부는 "부분 주문" 원장으로 해결할 수 있습니다. 부분 순서에서는 다른 모든 이벤트와 관련된 각 이벤트의 정확한 순서를 알 수 없습니다. 대신 관련 이벤트의 순서만 알려져 있습니다. 우리는 모든 사건의 순서를 확신할 수 없지만 상호 의존적인 사건의 순서는 결정할 수 있습니다.
예를 들어 이벤트 B가 이벤트 C보다 먼저 발생했다고 확인할 수 있습니다. 그러나 부분적으로 정렬된 시스템에서는 이벤트 A가 언제 발생할지 확신할 수 없습니다. 이벤트 A는 이러한 이벤트 이전, 이후 또는 사이에 발생할 수 있습니다. 이벤트 A는 다른 이벤트와 관련이 없습니다.
일반적으로 이러한 거래가 어떻게 주문되는지 알고자 하는 이유는 무엇입니까? 한 사건이 어떻게 다른 사건을 일으켰는지 알고 싶기 때문입니다. 부분 순서에는 시간 개념이 없으므로 각 이벤트가 언제 발생했는지 알지 못한 채 어떻게 이벤트를 정렬합니까?
"Causal ordering"이 이 문제에 대한 해결책입니다. 인과적 순서화는 사건이 발생하는 시간을 고려하지 않고 사건 간의 인과관계만을 고려하는 부분적 순서화이다. 어떤 이벤트가 다른 이벤트를 유발했는지 확인할 수 있는 한 이러한 이벤트를 주문할 수 있습니다.
위의 그림은 인과 관계의 예입니다. 위 이미지의 이벤트는 타임스탬프가 표시되지 않으므로 이러한 이벤트가 언제 발생했는지 정확히 확인할 수 없습니다. 그러나 A는 B를 발생시키고 B는 C와 E를 발생시킨다는 것을 알 수 있습니다. 그런 다음 A가 결국 D와 F를 발생시킨다는 결론을 내릴 수 있습니다. C가 D를 유발하고 E가 F를 유발하므로 C와 D, E와 F의 인과적 순서를 결정할 수 있습니다. 그러나 우리는 C와 E 또는 C와 F의 순서를 결정할 필요가 없으며 C 또는 D에 대한 E의 순서도 결정할 필요가 없습니다. 모든 이벤트가 부분적으로 순서 지정되고 서로 인과 관계가 있는 것은 아니지만 관련 없는 이벤트가 서로 상대적으로 순서 지정될 필요가 없기 때문에 괜찮습니다.
인과적 순서를 사용하면 더 이상 "이벤트 체인"과 같은 구조에 제한되지 않으므로 DAG 구조를 구축할 수 있습니다. 서로 관련이 없는 이벤트는 정렬할 필요가 전혀 없습니다. 인과적 순서의 거래의 분산 원장 구조는 DAG이고 전체 주문의 원장 구조는 블록체인입니다. 인과적 순서는 특정 트랜잭션이 순서를 완전히 건너뛸 수 있게 하므로 DAG 기반 원장은 블록체인 기반 원장에 비해 처리량 및 대기 시간 측면에서 확장성 이점이 있습니다.
첫 번째 레벨 제목
보조 제목
완전히 주문된 블록체인은 DAG를 어떻게 사용합니까?
텍스트
Fantom: DAG 기술을 사용한 Gossip 프로토콜 기반의 블록체인
이미지 설명
높은 수준에서 노드는 DAG를 형성하는 이벤트 블록을 생성합니다. 팬텀은 이 이벤트 블록의 DAG를 사용하여 블록체인(확인된 블록의 체인)을 생성합니다.
Fantom은 재무, 기술 및 기타 정보를 포함하는 이벤트 블록에 데이터를 저장합니다. 이벤트 블록은 네트워크를 통해 트랜잭션 및 사용자 정보를 공유하기 위해 단일 노드에서 생성된 데이터 구조입니다. 위 그림에서 우리가 보는 것은 DAG 구조이고 원은 노드를 나타내며 이벤트 블록은 노드에 의해 생성됩니다. 위 그림에는 나와 있지 않지만 각 노드는 실제로 이벤트 블록을 생성하고 있습니다. 노드가 트랜잭션 정보를 교환할 때마다 새로운 공유 이벤트 블록이 생성됩니다. 이벤트 블록은 네트워크에서 공유됩니다. 이벤트 블록이 다른 이벤트 블록과 통신할 때 통신한 이벤트 블록은 이전 이벤트 블록의 트랜잭션 정보를 저장한 후 새로운 이벤트 블록을 생성합니다. 이 정보는 다음 이벤트 블록으로 전달됩니다. 트랜잭션 정보는 해시되며 각 이벤트 블록에는 하나 이상의 이전 이벤트 블록의 해시 값이 포함됩니다. 이것은 해시를 변경하지 않고는 이전 이벤트 블록을 수정하거나 삭제할 수 없기 때문에 데이터를 변경할 수 없게 만듭니다.
위 그림과 같이 Opera Chain의 DAG 구조에서 초록색 영역이 이벤트 블록이며, "Clotho" 블록(위 그림에서 파란색 블록)이라는 이벤트 블록을 찾을 때까지 서로 통신을 합니다. . Clotho 블록에는 특정 이벤트에 대한 블록 간의 모든 연결 데이터를 보유하는 데이터 구조인 "태그 테이블"이 포함되어 있습니다. Clotho 블록으로 간주되려면 Clotho는 이전에 설정된 이벤트 블록에 대해 2/3 이상의 절대 다수 연결이 있어야 합니다. Clotho 블록은 태그 테이블 데이터 구조를 통해 DAG 구조의 다른 Clotho 블록과 통신합니다.
서로 간의 통신 정보를 기반으로 Clotho 블록은 합의에 도달하여 "Atropos" 블록(위 다이어그램의 녹색 블록)이라는 또 다른 이벤트 블록을 생성합니다. 각 Clotho 블록은 생성될 때 특정 타임스탬프를 가집니다. Clotho 블록은 모든 노드의 2/3 이상이 동일한 노드 시간을 가질 경우 Atropos 블록이 됩니다. 이러한 Atropos 블록은 서로 연결되어 "메인 체인"을 형성합니다. 메인 체인은 DAG 구조에서 블록체인으로 볼 수 있습니다. 각 Atropos 블록은 다른 Atropos 블록과 연결되어 Clothos 블록에서 수집한 정보를 공유하고, Clothos 블록은 다른 모든 이벤트 블록에서 정보를 가져옵니다.
이 메인 체인에는 모든 이벤트의 전체 순서가 포함됩니다. 모든 참여 노드는 메인 체인의 사본을 가지고 있으며 Lachesis 합의 프로토콜에서 블록의 과거 위치를 검색할 수 있습니다. 노드는 각 이벤트 블록에 대한 모든 정보를 저장할 필요가 없으며 메인 체인만 참조하면 됩니다. 이를 통해 시스템은 이전 이벤트에 빠르게 액세스할 수 있습니다.
첫 번째 레벨 제목
인과적으로 정렬된 출력이 있는 DAG
대부분의 사람들이 "DAG"라고 부르는 것은 실제로 인과적으로 정렬된 분산 원장입니다. 이러한 DAG는 어떻게 작동하며 상대적 총 주문과 어떻게 다릅니까? Avalanche의 X-Chain, IOTA 및 Sui는 인과 관계가 있는 분산 원장의 예입니다.
UTXO 기반 DAG인 Avalanche X-Chain.
Bitcoin은 지갑 간의 전송 상태를 기록하기 위해 UTXO(Unspent Transaction Output) 모델을 도입했습니다. 각 UTXO는 소유권 체인이며 소유자는 UTXO의 소유권을 새 소유자의 주소로 이전하는 트랜잭션에 서명합니다. UTXO의 맥락에서 비트코인은 블록체인으로, Avalanche의 X-Chain은 DAG로 설명되어야 합니다. X-Chain은 인과 관계의 Avalanche 합의 프로토콜을 사용합니다. 누군가에게 AVAX를 보낼 때 X-Chain을 사용하고 있습니다. Avalanche의 DAG 작동 방식을 이해하려면 먼저 Avalanche의 DAG 구조가 어떻게 형성되는지 알아야 합니다.
Avalanche 합의는 Slush, Snowflake, Snowball 및 Avalanche의 네 가지 주요 단계로 나뉩니다. Avalanche 컨센서스의 마지막 단계는 Snowman 컨센서스이며 나중에 살펴볼 것입니다. 먼저 Slush 합의가 어떻게 작동하는지 살펴보겠습니다. Avalanche 네트워크는 많은 노드로 구성됩니다. 각 노드에는 stateless, true 및 false의 세 가지 상태가 있습니다. 아래에서는 보다 직관적으로 표현하기 위해 무색, 파란색 및 빨간색을 사용합니다.
각 노드는 무색으로 시작하여 참 또는 거짓(파란색 또는 빨간색)을 결정하는 투표에 직면합니다. 색상이 선택되면 노드는 네트워크의 수많은 다른 노드와 통신합니다. 이러한 노드에 아직 색상이 없으면 노드와 동일한 색상을 사용합니다. 대부분의 노드가 같은 색상이면 원래 노드가 해당 투표를 유지합니다. 대부분의 노드가 다른 색상이면 원래 노드는 투표를 해당 색상으로 반전합니다.
모든 노드가 합의에 도달할 때까지 노드 간에 여러 라운드의 통신이 있을 것입니다. 목표는 각 노드가 일관된 색상을 형성하도록 하는 것입니다. 노드가 특정 색상 쪽으로 기울어지면 해당 기울기를 강화하고 올바른 결과를 해당 색상으로 향하게 합니다. 이 개념은 Avalanche가 구축되고 모든 것이 구축되는 토대입니다.
Avalanche의 두 번째 빌딩 블록은 Snowflake 프로토콜입니다. 노드가 메모리를 가져올 때 각 노드에는 카운터가 있습니다. 카운터는 Slush 프로토콜 통신이 동일한 색상을 반환할 때마다 1씩 증가합니다. 그리고 노드 반전 결과가 다른 색상을 반환할 때마다 카운터가 재설정됩니다. 카운터가 충분히 큰 숫자에 도달하면 상태를 잠그고 노드의 색상이 변경되지 않도록 합니다. 이렇게 하면 트루 컬러를 굳히는 데 도움이 됩니다.
Snowball 프로토콜의 세 번째 단계에서 노드는 더 큰 메모리로 값을 기록합니다. Snowball 프로토콜은 Snowflake 프로토콜에 신뢰도를 더합니다. Snowflake 프로토콜의 노드는 통신하는 다른 노드를 기반으로 색상을 변경하지 않고 대신 자신의 모든 색상 변경 내역을 검토하고 노드의 투표 변경 내역 데이터를 고려한 노드의 신뢰 상태를 기반으로 색상을 변경합니다.
위의 모든 단계는 결국 Avalanche 프로토콜로 이어집니다. Avalanche는 추가 전용(이전 트랜잭션에 트랜잭션 추가) DAG 구조입니다. 계약 체인(C-Chain) 및 플랫폼 체인(P-Chain)에서 Avalanche의 선형 구조의 경우와 마찬가지로 Avalanche는 DAG 구조 없이도 실행할 수 있습니다. Avalanche 컨센서스의 개발팀인 Team Rocket은 DAG 아키텍처가 블록체인보다 우월하다고 생각합니다. DAG 아키텍처의 각 트랜잭션에 대한 투표가 추가된 모든 트랜잭션에 연결되어 있기 때문에 DAG 투표 메커니즘이 더 효율적이기 때문입니다.
눈사태 합의는 알려진 모든 트랜잭션의 동적 DAG를 구축하기 위한 여러 Snowball 이벤트로 구성됩니다. 각 Snowball 이벤트는 그래프의 정점입니다. 정점은 선형 블록체인의 블록과 같습니다. 여기에는 부모의 해시와 트랜잭션 목록이 포함됩니다. Avalanche 합의는 Snowball을 기반으로 하며 신뢰도 개념은 여전히 유효하지만 DAG의 각 노드에 적용됩니다. 앞에서 논의한 빨강-파랑 결정과 달리 Avalanche 합의의 노드는 트랜잭션이 올바른지 또는 다른 트랜잭션과 충돌하는지 여부를 판단하고 서로 합의에 도달합니다. 모든 트랜잭션은 상위 트랜잭션에 연결되고 모든 상위 트랜잭션은 제네시스 정점에 다시 연결됩니다. 트랜잭션에는 하위 트랜잭션이 있을 수 있으며 하위 트랜잭션은 모든 상위 트랜잭션에 연결됩니다. Avalanche는 트랜잭션이 다른 모든 트랜잭션의 기초가 되어야 하기 때문에 제네시스 정점이 필요합니다(IOTA에도 제네시스 정점이 있음) 추가 작업만 지원하는 트랜잭션에는 추가 본문이 필요하기 때문에 제네시스 정점이 중요합니다. 그러나 노드로 구성된 DAG에 Snowball을 직접 적용하면 트랜잭션 충돌이나 이중 지출이라는 미해결 문제가 발생합니다. 그래서 Avalanche는 Snowball에 "chit"이라는 개념을 추가했습니다. 신뢰도가 임계값에 도달하면 값이 "1"인 트랜잭션에 chit라는 카운터가 추가됩니다. 할당되지 않은 경우 잡담 카운터는 "0"입니다. 이 노드는 Snowball의 신뢰도와 유사한 추가 신뢰도 설정으로 chit 값을 합산합니다. 그런 다음 노드는 전표의 합계를 사용하여 트랜잭션 및 모든 하위 트랜잭션(노드에 추가된 새 트랜잭션)의 신뢰도를 결정합니다.
Avalanche는 Slush, Snowflake 및 Snowball을 통합하고 선형 체인으로 조정할 수 있습니다. 이것은 상당히 다른 Avalanche 합의와 유사한 Snowman 합의에 대해 수행됩니다. Avalanche의 UTXO 모델과 달리 Snowman 합의는 계정 기반입니다. Snowman 합의는 Avalanche 네트워크의 플랫폼 체인(P-chain)과 계약 체인(C-chain)에 사용됩니다. 프로토콜은 위와 동일하게 작동하지만 각 정점에는 여러 부모 대신 하나의 부모만 있습니다. 따라서 모든 정점은 전체 순서를 형성합니다. 이것은 또한 전체 구조를 DAG가 아닌 블록체인으로 렌더링합니다. 이는 트랜잭션의 순서를 알아야 하는 애플리케이션에 유용하며 Snowman 합의는 스마트 계약도 지원합니다.
Avalanche 컨센서스 프로토콜은 통화 전송에 놀랍도록 잘 작동하며 다양한 다른 프로토콜에도 적용될 수 있습니다. Avalanche는 자체 프로젝트인 Bitcoin ABC에 대한 하드 포크 이전에 Bitcoin Cash의 사전 합의 메커니즘으로 사용되었습니다. Avalanche의 DAG 구조는 트랜잭션 속도를 향상시키고 Bitcoin Cash는 스마트 계약을 요구하지 않기 때문에 DAG와 스마트 계약의 비호환성 결함은 이에 영향을 미치지 않습니다. 결제 분야에서 Avalanche는 스마트 계약의 필요성을 무시할 수 있으며 DAG 기반 원장이 기능을 보다 효과적으로 확장할 수 있는 방법만 강조합니다.
작업 증명을 사용하는 트랜잭션 기반 DAG인 IOTA
IOTA의 인과적 순서 구조는 트랜잭션을 병렬로 처리하는 네트워크인 Tangle이라고 합니다. Tangle은 IOTA가 DAG를 구성하는 데이터 구조입니다. IOTA의 탱글은 트랜잭션으로 구성되며 각 트랜잭션은 그래프에서 정점으로 표시됩니다. 새 트랜잭션이 Tangle에 합류하면 승인을 위해 두 개의 이전 트랜잭션을 선택하고 그래프에 두 개의 새 링크를 추가합니다.
아래 다이어그램에서 트랜잭션 G는 트랜잭션 E와 F를 승인합니다. 트랜잭션에는 "Alice가 Bob에게 IOTA 코인 10개를 주었다"와 같은 정보가 포함됩니다. 승인되지 않은 거래를 "팁"이라고 합니다. 거래 G는 아직 승인되지 않았기 때문에 팁입니다. 새로 추가된 각 트랜잭션은 두 개의 보류 중인 팁과 연결되어야 합니다. 팁 선택에 도움이 되는 몇 가지 전략이 있지만 가장 간단한 방법은 승인할 팁 두 개를 무작위로 선택하는 것입니다. 승인을 위한 팁을 선택하는 프로세스는 새로운 거래에 대해 매우 확장 가능합니다.
빨간색 거래 I 및 G는 다른 거래와 연결되어 있지 않기 때문에 승인되지 않은 팁입니다. 각 거래에는 연결된 다른 거래가 있기 때문에 다른 모든 거래는 이미 승인되었습니다.
동시에 IOTA는 IOTA DAG 아키텍처를 강화하는 중요한 개념인 가중치를 도입했습니다. 트랜잭션이 신뢰할 수 있는지 어떻게 알 수 있습니까? 일반적인 블록체인에서는 블록체인의 확인 횟수를 보는 것이 일반적입니다. IOTA는 거래 가중치를 살펴봄으로써 유사한 기능을 달성합니다.
이미지 설명
각 트랜잭션에는 자체 가중치가 있으며 Tangle에 팁이 추가될 때마다 누적 가중치가 증가합니다.
위의 다이어그램에서 트랜잭션 D는 트랜잭션 E와 H에 의해 직접 승인되고 G와 I에 의해 간접적으로 승인되는 것을 볼 수 있습니다. 따라서 D의 누적 가중치는 3+1+3+1+1=9이며, 이는 자신의 가중치에 E, H, G, I의 가중치를 더한 값입니다.
누적 가중치가 큰 트랜잭션이 누적 가중치가 작은 트랜잭션보다 더 중요합니다. 탱글에 추가되는 각각의 새로운 트랜잭션은 자체 트랜잭션의 가중치만큼 이전 트랜잭션의 누적 가중치를 증가시킵니다. 오래된 트랜잭션은 시간이 지남에 따라 더욱 중요해집니다. 어떠한 주체도 단기간에 충분한 가중치를 가진 트랜잭션을 생성할 수 없다고 생각할 수 있으므로 누적 가중치를 사용하면 스팸 공격 및 기타 벡터 공격을 피할 수 있습니다.
Avalanche의 X-Chain과 유사하게 이 접근 방식은 확장성이 높지만 스마트 계약을 통합하는 것을 거의 불가능하게 만듭니다. 따라서 다른 스마트 계약 체인과 경쟁하기 위해 IOTA는 "Assembly"라는 별도의 스마트 계약 레이어를 시작합니다. Assembly는 EVM 및 WASM 스마트 계약을 지원하도록 설계된 완전히 주문된 레이어 2입니다.
Sui, Proof of Stake를 이용한 스마트 컨트랙트 DAG
Sui는 이 보고서에서 인과적 순서로 분류되지만 실제로 Sui는 전체 순서와 인과적 순서를 모두 사용합니다. Sui의 트랜잭션 처리 아키텍처는 두 부분으로 볼 수 있습니다. 한 부분은 완전히 주문되고 순차적으로 실행되는 종속 트랜잭션이고 다른 부분은 인과적으로 주문되고 병렬로 실행되는 독립 트랜잭션입니다. 종속 트랜잭션은 Sui의 Narwhal 및 Bullshark 프로토콜을 사용합니다. Narwhal은 DAG 기반 멤풀인 반면 Bullshark는 합의를 위해 Narwhal과 통합되는 합의 프로토콜입니다. 종속 트랜잭션은 연결된 다른 트랜잭션과 순서대로만 실행하면 됩니다. 그러나 Sui는 트랜잭션이 완전히 독립적일 때 다른 접근 방식을 취합니다. 독립형 트랜잭션의 경우 Narwhal 및 Bullshark 대신 Sui는 BCB(Byzantine Consensus Broadcasting)라는 방법을 사용합니다. 이 방법은 글로벌 합의가 필요하지 않으므로 트랜잭션을 거의 즉시 처리하고 원장에 쓸 수 있습니다.
이미지 설명
트랜잭션 순서에 관계없이 모든 트랜잭션은 동일한 네트워크에서 병렬로 처리됩니다.
트랜잭션은 단순히 개체의 특정 인스턴스에 대한 메타데이터 변경입니다. 트랜잭션은 개체를 입력으로 사용하고 해당 입력 개체를 읽거나 쓰거나 변경하여 새로 생성되거나 업데이트된 개체를 출력으로 생성합니다. 각 개체는 자신을 생성한 이전 개체의 해시를 알고 있습니다.
이미지 설명
Sui의 원장은 데이터가 DAG에 저장되는 "개체 저장소" 또는 "개체 풀"입니다. 예를 들어 USDC를 보내는 행위는 한 개체의 "소유자" 속성을 업데이트하는 행위이며 다른 개체에는 영향을 미치지 않습니다.
Sui의 원장은 데이터가 DAG에 저장되는 "개체 저장소" 또는 "개체 풀"입니다. 이 DAG에서 노드는 개체이며 그래프의 각 화살표는 지정된 개체의 속성을 업데이트하는 트랜잭션을 나타냅니다. 이 다이어그램에 표시되지 않은 제네시스 트랜잭션은 시스템의 초기 상태에서 입력을 받지 않고 개체를 생성합니다.
키 포인트
키 포인트
트랜잭션의 인과적 순서는 속도와 처리량 측면에서 전체 순서보다 이점이 있는 것으로 보입니다. 그러나 순서의 인과적 순서가 없기 때문에 엄격한 연대순 순서가 필요한 애플리케이션을 만들려고 할 때 문제가 발생하고 많은 프로젝트가 DAG 아키텍처에서 스마트 계약을 제대로 실행하지 못합니다. 블록체인 구조와 유사한 Fantom의 완전 주문 아키텍처는 EVM 및 스마트 계약을 지원합니다. Fantom은 총 주문 출력을 가지고 있지만 개발자는 여전히 DAG 합의 메커니즘에서 레이어 1을 최적화하는 방법을 찾았습니다. Avalanche는 EVM 및 스마트 계약의 편리한 개발을 지원하기 위해 별도의 합의 메커니즘 Snowman을 만드는 다른 접근 방식을 선택했습니다. IOTA는 또한 다른 접근 방식을 선택했으며 EVM을 지원하기 위해 IOTA에 블록체인 인스턴스를 쉽게 배포할 수 있는 프레임워크를 만들어 완전히 주문된 레이어 2 인프라를 효과적으로 생성하고 있습니다. Sui의 독특한 디자인은 매우 유망합니다.거래는 필요에 따라 완전히 주문하거나 인과적으로 주문할 수 있습니다.스마트 계약과 호환되며 대기 시간을 줄일 수 있습니다.
Sui는 최신 DAG 기반 Layer 1이지만 Sui는 이전 아키텍처의 단점을 개선하고 차별화를 달성했기 때문에 Sui는 DAG를 진정한 분산 원장으로 만드는 구조를 구현했습니다. 인과 거래가 미래에 주류가 되지 않더라도 DAG 기반 기술은 기존 블록체인을 확장하는 데 도움이 될 것입니다. 스케일링 방법으로서 DAG가 모든 사용 사례에 최선의 선택은 아닐 수 있지만 Avalanche의 X-Chain 및 IOTA에서 DAG는 대기 시간 및 처리량 측면에서 좋은 성능을 발휘하는 것으로 보입니다.
보조 제목
저자에 대해
부인 성명
부인 성명
여기에 포함된 정보("정보")는 정보 제공의 목적으로만 요약된 형태로 제공되며 완전하지 않습니다. 이러한 자료는 유가 증권 또는 제품을 판매하거나 구매하기 위한 제안 또는 권유가 아니며 그러한 의도도 없습니다. 이러한 정보는 제공되지 않으며 투자 조언을 제공하는 것으로 간주되어서는 안 됩니다.
원본 링크
