XRPL Docs (Korean)
  • XRPL Docs(Kor)
  • Introduction
    • XRP Ledger란?
    • XRP란?
    • Crypto Wallets
    • Transactions and Requests
    • Software Ecosystem
  • Use Cases
    • 결제(Payments)
      • P2P 결제(Peer-to-Peer Payments)
      • 예금 제한(Restricting Deposits)
      • 스마트 컨트랙트(Smart Contracts)
    • 토큰화(Tokenization)
      • 스테이블코인 발행인(Stablecoin Issuer)
      • NFT 마켓플레이스 개요(NFT Marketplace Overview)
    • 탈중앙화 금융(Decentralized Finance)
      • 알고리즘 트레이딩(Algorithmic Trading)
      • 거래소에 XRP 상장하기((List XRP as an Exchange)
  • Concepts
    • 소개
      • 컨센서스 소개
      • XRP
      • 소프트웨어 생태계
    • XRP Ledger 서버
      • rippled 서버 모드(rippled Server Modes)
      • 클러스터링(Clustering)
      • Ledger 역사
      • 피어 프로토콜(Peer Protocol)
      • 트랜잭션 검열 감지(Transaction Censorship Detection)
      • 병렬 네트워크(Parallel Networks)
      • 수정안(Amendments)
        • XRP Ledger에 코드를 기여하는 방법
        • 알려진 수정안
      • 클리오 서버(The Clio Server)
    • 컨센서스 네트워크(Consensus Protocol)
      • 컨센서스 구조(Consensus Structure)
      • 컨센서스 원칙과 규칙(Consensus Principles and Rules)
      • 공격과 실패 모드에 대한 컨센서스 보호(Consensus Protections Against Attacks and Failure Modes)
      • 불변성 체크
      • 부정 UNL
      • 트랜잭션 취소 정보
      • 트랜잭션 변조 가능성
      • 수수료 투표
      • 컨센서스 연구
    • Ledgers
      • Ledger 구조(Ledger Structure)
      • 개방형, 폐쇄형, 검증형 Ledgers(Open, Closed, and Validated Ledgers)
      • Ledger 마감 시간(Ledger Close Times)
    • 트랜잭션(Transactions)
      • 수수료(Fees)
      • 신뢰할 수 있는 트랜잭션 제출(Reliable Transaction Submission)
      • 보안 서명(Secure Signing)
      • 출발, 데스티네이션 태그(Source and Destination Tags)
      • 트랜잭션 비용(Transaction Cost)
      • 트랜잭션 대기열(Transaction Queue)
      • 결과의 불변성(Finality of Results)
        • 트랜잭션 결과 조회(Look Up Transaction Results)
        • Transaction Malleability
    • 결제 유형
      • XRP 직접 결제
      • 교차 화폐 결제
      • 수표
      • 에스크로
      • 부분 결제
      • 결제 채널
    • 토큰(Tokens)
      • Non-Fungible Tokens
        • NFT 정보 저장소(NFT Payload Storage)
        • XRP Ledger에서 NFT 토큰 거래(Trading NFTokens on the XRP Ledger)
        • NFT Reserve Requirements
        • 일괄 발행(Batch minting)
        • 다른 계정에게 NFT 발행 권한 부여(Authorizing Another Account to Mint Your NFTs)
        • NFT 경매 진행하기(Running an NFT Auction)
        • NFT를 컬렉션으로 발행하기(Minting NFTs into Collections)
        • NFT의 고정 공급 보장하기(Guaranteeing a Fixed Supply of NFTs)
        • NFT 관련 API(NFT APIs)
      • 신뢰선과 발급(Trust Lines and Issuing)
      • 승인된 신뢰선(Authorized Trust Lines)
      • 토큰 환수(Clawing Back Tokens)
      • Freezing Tokens(토큰 동결)
        • 동결에 대한 일반적인 오해(Common Misunderstandings about Freezes )
      • Rippling
      • 이체 수수료(Transfer Fees)
      • 경로(Paths)
      • Demurrage(과잉보유비용)
      • 탈중앙화 거래소(Decentralized Exchange)
        • 제안(Offers)
        • Auto-Bridging
        • Tick Size
        • AMM(Automated Market Makers)
    • 계정
      • 다중 서명
      • 티켓
      • 계정 유형
      • 계정 삭제
      • 준비금(Reserves)
      • 주소(Addresses)
      • 암호화 키(Cryptographic Keys)
      • 입금 승인(Deposit Authorization)
  • Tutorials
    • 퍼블릭 서버(Public Servers)
    • Python
      • Python으로 시작하기(Get Started Using Python)
      • python 모듈형 튜토리얼(Modular Tutorials in Python)
        • python을 이용한 Send Payments(Send Payments Using Python)
          • 계정 생성 및 XRP 전송(Create Accounts and Send XRP Using Python)
          • 신뢰 생성 및 Currency 전송 (Create Trust Line and Send Currency Using Python)
          • 시간 보류 에스크로 생성(Create Time-based Escrows Using Python)
        • python을 이용한 NFTs(NFTs Using Python)
          • NFTs 발행과 소각(Mint and Burn NFTs Using Python)
          • NFTs 전송 (Transfer NFTs Using Python)
          • NFT 판매 중개 (Broker an NFT Sale Using Python)
          • 공인 발행인 지정 (Assign an Authorized Minter Using Python)
          • NFTs 일괄 발행 (Batch Mint NFTs Using Python)
        • Python에서 데스크톱 지갑 구축(Build a Desktop Wallet in Python)
    • JavaScript
      • JavaScript로 시작하기(Get Started Using JavaScript)
      • JavaScript 모듈형 튜토리얼(Modular Tutorials in JavaScript)
        • JavaScript를 이용한 Send Payments(Send Payments Using JavaScript)
          • JavaScript를 이용한 계정 생성 및 XRP 전송(Create Accounts and Send XRP Using JavaScript)
          • JavaScript를 이용한 신뢰선 생성 및 화폐 전송(Create Trust Line and Send Currency Using JavaScript)
          • 시간 기반 에스크로 생성하기(Create Time-based Escrows Using JavaScript)
          • 조건부 에스크로 생성하기(Create Conditional Escrows Using JavaScript)
        • JavaScript를 이용한 NFTs(NFTs Using JavaScript)
          • JavaScript를 이용한 NFTs 발행 및 소각(Mint and Burn NFTs Using JavaScript)
          • JavaScript를 이용한 NFTs 전송(Transfer NFTs Using JavaScript)
          • JavaScript를 이용한 NFT 판매 중개(Broker an NFT Sale Using JavaScript)
          • JavaScript를 이용한 공인 발행인 지정(Assign an Authorized Minter Using JavaScript)
          • JavaScript를 이용한 NFTs 일괄 발행(Batch Mint NFTs Using JavaScript)
      • JavaScript를 이용한 브라우저 지갑 개발(Build a Browser Wallet in JavaScript)
      • JavaScript를 이용한 데스크탑 지갑 개발(Build a Desktop Wallet in JavaScript)
    • Java
      • Java로 시작하기(Get Started Using Java)
    • HTTP / Websocket APIs
      • HTTP/WebSocket API 사용 시작하기(Get Started Using HTTP / WebSocket APIs)
      • WebSocket으로 수신 결제 모니터링(Monitor Incoming Payments with WebSocket)
    • Tasks
      • 계정 설정 관리(Manage Account Settings)
        • 일반 키 쌍 할당
        • 일반 키 쌍 변경 또는 제거
        • 마스터 키 쌍 비활성화
        • 다중 서명 설정
        • 다중 서명 트랜잭션 전송
        • 데스티네이션 태그 필요
        • 오프라인 계정 설정 튜토리얼
        • 티켓 사용(Use Tickets)
      • XRP 보내기(Send XRP)
      • 특수 결제 유형 사용(Use Specialized Payment Types)
        • 에스크로 사용(Use escrow)
          • 시간 보류 에스크로 보내기(Send a Time-Held Escrow)
          • 조건부 보류 에스크로 보내기(Send a Conditionally-Held Escrow)
          • 만료된 에스크로 취소(Cancel an Expired Escrow)
          • 에스크로 조회(Look up Escrows)
          • 에스크로를 스마트 컨트랙트로 사용(Use an Escrow as a Smart Contract)
        • 결제 채널 사용(Use Payment Channels)
          • 결제 채널을 열어 거래소 간 네트워크 활성화(Open a Payment Channel to Enable an Inter-Exchange Network)
        • 수표 사용(Use Checks)
          • 수표 전송(Send a Check)
          • 정확한 금액의 수표 현금화(Cash a Check for an Exact Amount)
          • 유연한 금액의 수표 현금화(Cash a Check for a Flexible Amount)
          • 수표 취소(Cancel a Check)
          • 발신자별 수표 조회(Look Up Checks by Sender)
          • 수취인별 수표 조회(Look Up Checks by Recipient)
      • 토큰 사용(Use Tokens)
        • 대체가능한 토큰 발행(Issue a Fungible Token)
        • 탈중앙화 거래소에서 거래(Trade in the Decentralized Exchange)
        • 동결 금지 활성화
        • 글로벌 동결 시행
        • 신뢰선 동결하기
    • Apps 구축
      • JS에서 데스크톱 지갑 구축
      • JS에서 브라우저 지갑 구축
    • XRP Ledger 비즈니스
      • XRP 차트에 거래소 등록하기
      • 스테이블코인 발행자 되기
    • rippled 서버 관리
      • rippled 설치
        • 시스템 요구 사항
        • CentOS/Red Hat에 yum으로 설치하기
        • 우분투 또는 데비안 리눅스에 설치
        • 리눅스에서 자동 업데이트
        • CentOS/Red Hat에서 수동 업데이트
        • 우분투 또는 데비안에서 수동 업데이트
        • 리포팅 모드에서 rippled 빌드 및 실행
        • 용량 계획
        • rippled v1.3.x 마이그레이션 지침
      • rippled 구성
        • rippled를 검증인으로 실행하기
        • rippled를 스톡 서버로 실행
        • 수정안 투표 구성
        • 수정안 테스트
        • StatsD 구성
        • rippled를 병렬 네트워크에 연결하기
        • 온라인 삭제 구성
        • 권고 삭제 구성
        • 히스토리 샤딩 구성
        • 전체 히스토리 구성
        • gRPC 구성
        • 공개 서명 사용
      • 피어링 구성
        • 클러스터 rippled 서버
        • 비공개 서버 구성
        • 피어 크롤러 구성
        • 링크 압축 사용
        • 피어링을 위한 포트 포워드
        • 특정 피어에 수동으로 연결
        • 최대 피어 수 설정
        • 피어 예약 사용
      • stand-alone 모드에서 rippled 기능 테스트하기
        • stand-alone 모드에서 새 제네시스 ledger 시작하기
        • stand-alone 모드에서 저장된 ledger 불러오기
        • stand-alone 모드에서 ledger 진행하기
      • 문제 해결
        • rippled 문제 진단하기
        • 상태 확인 개입
        • 로그 메시지 이해
        • rippled 서버가 동기화되지 않음
        • rippled 서버가 수정이 차단됨
        • rippled 서버가 시작되지 않음
        • SQLite 트랜잭션 데이터베이스 페이지 크기 문제 해결
    • 클리오 서버 관리
      • 우분투 리눅스에 클리오 설치
  • References
    • XRP Ledger 프로토콜 참조(XRP Ledger Protocol Reference)
      • 기본 데이터 유형(Basic Data Types)
        • base58 인코딩(base58 Encodings)
        • 화폐 형식(Currency Formats)
        • NFToken
      • Ledger 데이터 형식(Ledger Data Formats)
        • Ledger 헤더(Ledger Header)
        • Ledger 객체 IDs
        • Ledger 객체 유형
          • AccountRoot
          • Amendments
          • AMM(experimental - 수정중)
          • Check
          • DepositPreauth
          • DirectoryNode
          • Escrow
          • FeeSettings
          • LedgerHashes
          • NegativeUNL
          • NFTokenOffer
          • NFTokenPage
          • Offer
          • PayChannel
          • RippleState
          • SignerList
          • Ticket
      • 트랜잭션 참조(Transaction Reference)
        • 트랜잭션 공통 필드(Transaction Common Fields)
        • 트랜잭션 유형(Transaction Types)
          • AccountSet
          • AccountDelete
          • AMMBid
          • AMMCreate
          • AMMDelete
          • AMMDeposit
          • CheckCancel
          • CheckCash
          • CheckCreate
          • DepositPreauth
          • EscrowCancel
          • EscrowCreate
          • EscrowFinish
          • NFTokenAcceptOffer
          • NFTokenBurn
          • NFTokenCancelOffer
          • NFTokenCreateOffer
          • NFTokenMint
          • OfferCancel
          • OfferCreate
          • Payment
          • PaymentChannelClaim
          • PaymentChannelCreate
          • PaymentChannelFund
          • SetRegularKey
          • SignerListSet
          • TicketCreate
          • TrustSet
        • Pseudo-Transactions
          • EnableAmendment
          • SetFee
          • UNLModify
        • 트랜잭션 결과(Transaction Results)
          • tec Codes
          • tef Codes
          • tel Codes
          • tem Codes
          • ter Codes
          • tes Success
        • 트랜잭션 메타데이터(Transaction Metadata)
      • Binary Format
    • 클라이언트 라이브러리
      • JavaScript / TypeScript 클라이언트 라이브러
        • ripple-lib 1.x에서 xrpl.js 2.x로의 마이그레이션 가이드
      • Python 클라이언트 라이브러리
      • Java 클라이언트 라이브러리
      • Ruby 클라이언트 라이브러리
    • HTTP / WebSocket APIs
      • API 규칙
        • 요청 형식
        • 응답 형식
        • 오류 형식
        • 마커 및 페이지네이션
        • 속도 제한
        • rippled 서버 상태
      • 공개 API 메소드
        • 계정 메소드
          • account_channels
          • account_currencies
          • account_info
          • account_lines
          • account_nfts
          • account_objects
          • account_offers
          • account_tx
          • gateway_balances
          • noripple_check
        • Ledger 메소드
          • ledger
          • ledger_closed
          • ledger_current
          • ledger_data
          • ledger_entry
        • 트랜잭션 메소드
          • submit
          • submit_multisigned
          • transaction_entry
          • tx
          • tx_history
        • 경로와 오더북 메소드
          • book_offers
          • deposit_authorized
          • nft_buy_offers
          • nft_sell_offers
          • path_find
          • ripple_path_find
        • 결제 채널 메소드
          • channel_authorize
          • channel_verify
        • 구독 메소드
          • 구독
          • 구독 취소
        • Server Info 메소드
          • fee
          • manifest
          • server_info (rippled)
          • server_state
        • 클리오 서버
          • server_info
          • ledger
          • nft_history
          • nft_info
        • 유틸리티 메소드
          • json
          • ping
          • random
      • 관리자 API 메소드
        • 키 생성 방법
          • validation_create
          • wallet_propose
        • 로깅 및 데이터 관리 메소드
          • can_delete
          • crawl_shards
          • download_shard
          • ledger_cleaner
          • ledger_request
          • log_level
          • logrotate
          • node_to_shard
        • 서버 컨트롤 메소드
          • ledger_accept
          • stop
          • validation_seed
        • 서명 메소드
          • sign
          • sign_for
        • 피어 관리 메소드
          • connect
          • peer_reservations_add
          • peer_reservations_del
          • peer_reservations_list
          • peers
        • 상태 및 디버깅 메소드
          • consensus_info
          • feature
          • fetch_info
          • get_counts
          • print
          • validator_info
          • validators
        • rippled 커맨드라인 사용 참조
        • 피어 포트 메소드
          • 상태 확인
          • 피어 크롤러
          • 유효성 검증인 목록 메소드
    • xrp-ledger.toml File
  • Infrastructure
    • 커맨드 라인 사용법(Commandline Usage)
    • Install rippled
      • System Requirements
      • Install on CentOS/RedHat with yum
      • Install on Ubuntu or Debian Linux
      • Update Automatically on Linux
      • Update Manually on CentOS/Red Hat
      • Update Manually on Ubuntu or Debian
      • Build and Run rippled in Reporting Mode
      • Capacity Planning
    • Configure rippled
      • Server Modes
        • Run rippled as a Validator
        • Run rippled as a Stock Server
      • Data Retention
        • Configure Full History
        • 온라인 삭제(Online Deletion)
        • Configure Online Deletion
        • Configure Advisory Deletion
        • 히스토리 샤딩(History Sharding)
        • Configure History Sharding
      • Configure Amendment Voting
      • Test Amendments
      • Configure StatsD
      • Connect Your rippled to a Parallel Network
      • Configure gRPC
      • Enable Public Signing
    • Peering
      • Cluster rippled Servers
      • Configure a Private Server
      • Configure the Peer Crawler
      • Enable Link Compression
      • Forward Ports for Peering
      • Manually Connect to a Specific Peer
      • Set Maximum Number of Peers
      • Use a Peer Reservation
    • Testing and Auditing
      • Start a New Genesis Ledger in Stand-Alone Mode
      • Load a Saved Ledger in Stand-Alone Mode
      • Advance the Ledger in Stand-Alone Mode
    • Troubleshooting
      • Diagnosing Problems with rippled
      • Health Check Interventions
      • Understanding Log Messages
      • rippled Server Doesn't Sync
      • rippled Server is Amendment Blocked
      • rippled Server Won't Start
    • Install Clio on Ubuntu Linux
    • Run a Private Network with Docker
Powered by GitBook
On this page
  • 배경(Background)
  • 작동 방식(Mechanics)
  • 이중지불 문제(The Double Spend Problem)
  • 컨센서스 작동 방식(How Consensus Works)
  • 문제 단순화(Simplifying the Problem)
  • 컨센서스 규칙(Consensus Rules)
  • 컨센서스 라운드(Consensus Rounds)
  • 컨센서스 실패 가능성(Consensus Can Fail)
  • 컨센서스 실패 시 XRP Ledger의 처리 방법(How the XRP Ledger Handles Consensus Failure)
  • 철학(Philosophy)
  1. Concepts
  2. 컨센서스 네트워크(Consensus Protocol)

컨센서스 원칙과 규칙(Consensus Principles and Rules)

XRP Ledger는 이메일을 보내는 것과 같이 국경을 넘어 사용자가 자유롭게 자금을 이동할 수 있는 범용 결제 시스템입니다. 비트코인과 같은 다른 P2P 결제 네트워크와 마찬가지로 XRP Ledger는 분산된 컴퓨터 네트워크를 통해 P2P 거래 결제를 가능하게 합니다. 다른 디지털 통화 프로토콜과는 달리 XRP Ledger는 사용자가 선호하는 어떤 통화든지 포함하여 거래를 표시할 수 있습니다. 이는 법정 화폐, 디지털 화폐 및 기타 가치 형태와 XRP(똑같은 XRP Ledger의 기본 자산)를 포함합니다.

XRP Ledger의 기술은 실시간 정산(3~6초)을 가능하게 하며, 통화 간에 가장 저렴한 거래 순서를 자동으로 사용하여 통화 간 연결을 제공하는 탈중앙화 거래소(DEX)를 포함하고 있습니다.

배경(Background)

작동 방식(Mechanics)

XRP Ledger는 계정, 잔액, 자산 거래 요청과 같은 정보를 기록하는 공유 데이터베이스입니다. "트랜잭션"이라고 불리는 서명된 명령은 계정 생성, 지불, 자산 거래 등과 같은 변경을 발생시킵니다.

암호화 시스템으로서, XRP Ledger 계정의 소유자는 공개/비밀 키 쌍에 해당하는 암호학적 신원으로 식별됩니다. 트랜잭션은 이러한 신원과 일치하는 암호학적 서명에 의해 승인됩니다. 각 서버는 동일한 결정론적이고 알려진 규칙에 따라 모든 트랜잭션을 처리합니다. 궁극적으로, 네트워크의 모든 서버가 중앙 기관 없이도 정확히 동일한 ledger 상태의 완전한 사본을 갖도록 하는 것이 목표입니다. 이를 통해 거래를 중재하기 위한 단일한 중앙 기관 없이 완벽한 컨센서스를 이룰 수 있습니다.

이중지불 문제(The Double Spend Problem)

"이중지불" 문제는 모든 디지털 결제 시스템에 대한 근본적인 도전 과제입니다. 이 문제는 돈이 한 곳에서 사용되었을 때 다른 곳에서도 사용될 수 없다는 요구 사항에서 발생합니다. 더 일반적으로는 어느 한 거래라도 개별적으로는 유효하지만 함께 유효하지 않은 두 거래가 있는 경우에 문제가 발생합니다.

예를 들어, Alice, Bob, Charlie가 결제 시스템을 사용하는 상황을 가정해보겠습니다. Alice가 10달러의 잔액을 가지고 있다고 가정하면, 결제 시스템이 유효하려면 Alice는 10달러를 Bob에게 보낼 수 있어야 하거나 Charlie에게 보낼 수 있어야 합니다. 그러나 Alice가 동시에 Bob에게 10달러를 보내고 Charlie에게도 10달러를 보내려고 하면 이중지불 문제가 발생합니다.

만약 Alice가 "같은" 10달러를 Charlie와 Bob에게 모두 보낼 수 있다면 결제 시스템은 유용하지 않게 됩니다. 결제 시스템은 어떤 거래가 성공하고 어떤 거래가 실패해야 하는지 선택할 수 있는 방법이 필요합니다. 이 선택은 모든 참여자가 해당 거래가 발생한 것에 대해 동의하는 방식으로 이루어져야 합니다. 두 거래 중 어느 하나는 개별적으로는 동일하게 유효합니다. 그러나 결제 시스템의 참여자들은 어떤 거래가 먼저 발생했는지에 대해 서로 다른 시각을 가질 수 있습니다.

전통적으로, 결제 시스템은 중앙 기관이 거래를 추적하고 승인하는 방식으로 이중지불 문제를 해결합니다. 예를 들어, 은행은 은행 자체가 유일한 관리자인 발행자의 가용 잔액에 기반하여 수표를 처리하기로 결정합니다. 이러한 시스템에서는 모든 참여자가 중앙 기관의 결정을 따르게 됩니다.

XRP Ledger와 같은 분산 ledger 기술에는 중앙 기관이 없습니다. 이러한 시스템은 다른 방식으로 이중지불 문제를 해결해야 합니다.

컨센서스 작동 방식(How Consensus Works)

문제 단순화(Simplifying the Problem)

이중지불 문제의 많은 부분은 자금이 없는 계정에서 자금을 소비하는 것을 금지하는 등 이미 알려진 규칙에 따라 해결할 수 있습니다. 실제로, 이중지불 문제는 트랜잭션을 순서대로 정렬하는 것으로 간소화될 수 있습니다.

Alice가 Bob과 Charlie에게 동일한 10달러를 보내려고 하는 예를 생각해보겠습니다. 만약 Bob에 대한 결제가 먼저 알려진다면, 모두가 Alice가 Bob에게 지불할 자금이 있다는 것에 동의할 수 있습니다. 만약 Charlie에 대한 결제가 두 번째로 알려진다면, 이미 돈이 Bob에게 보내졌기 때문에 Alice가 그 자금을 Charlie에게 보낼 수 없다는 것에 모두 동의할 수 있습니다.

또한, 결정론적인 규칙에 따라 트랜잭션을 순서대로 정렬할 수 있습니다. 트랜잭션은 디지털 정보의 모음이므로 컴퓨터에서 정렬하는 것은 간단합니다.

이는 중앙 기관 없이도 이중지불 문제를 해결하는 데 충분하지만, 모든 거래가 발생하기 전에(정렬하기 위해 모든 거래를 갖고 있어야 함) 결과에 대해 확실성을 얻으려면 실현 불가능합니다. 이는 분산 ledger 기술에서는 현실적이지 않습니다.

만약 우리가 거래를 그룹으로 모을 수 있고 그룹화에 동의할 수 있다면 그룹 내에서 거래를 정렬할 수 있습니다. 모든 참여자가 거래가 하나의 단위로 처리되어야 한다는 점에서 합의한다면, 중앙 기관 없이도 결정론적인 규칙을 사용하여 이중지불 문제를 해결할 수 있습니다. 참여자들은 각각 거래를 정렬하고 알려진 규칙을 따라 결정론적인 방식으로 적용합니다. XRP Ledger는 이와 같은 방식으로 이중지불 문제를 해결합니다.

XRP Ledger는 동일한 그룹 내에 서로 충돌하는 여러 거래를 허용합니다. 그룹의 거래들은 결정론적인 규칙에 따라 실행되므로 정렬 규칙에 따라 먼저 발생한 거래가 성공하고 충돌하는 다른 거래가 두 번째로 발생합니다.

컨센서스 규칙(Consensus Rules)

컨센서스의 주요 역할은 참여자들이 그룹으로 처리될 거래를 어떻게 합의할지 결정하는 것입니다. 이러한 컨센서스를 이루는 것이 예상보다 쉬운 유형의 이유는 다음과 같습니다:

  1. 거래를 그룹에 포함시키는 데 아무런 이유가 없다면, 모든 성실한 참여자는 해당 거래를 포함시키기로 동의합니다. 모든 참여자가 이미 동의하는 경우에는 컨센서스 작업이 필요하지 않습니다.

  2. 거래를 그룹에 포함시키는 데 어떤 이유라도 있을 경우, 모든 성실한 참여자는 해당 거래를 제외하기로 동의합니다. 거래가 여전히 유효한 경우, 다음 라운드에 포함시키기 위해 어떤 이유도 없으므로 모두 동의해야 합니다.

  3. 참여자가 거래 그룹화에 특별히 관심을 갖는 경우는 매우 드뭅니다. 모두가 합의에 도달하기를 원하는 경우 합의가 가장 쉽게 이루어집니다. 그러나 이해관계가 상이한 경우 합의를 도달하기가 어려울 수 있습니다.

  4. 결정론적인 규칙은 그룹화를 형성하는 데도 사용될 수 있으며, 이는 극히 드물지만 의견이 다를 수 있는 극단적인 경우에만 의견이 분기될 수 있습니다. 예를 들어, 한 라운드에 충돌하는 두 개의 상충하는 거래가 있는 경우, 결정론적인 규칙을 사용하여 다음 라운드에 포함시킬 거래를 결정할 수 있습니다.

모든 참여자의 최우선 순위는 정확성입니다. 공유된 ledger의 무결성을 위해 먼저 규칙을 강제해야 합니다. 예를 들어, 올바르게 서명되지 않은 트랜잭션은 절대로 처리해서는 안 됩니다(다른 참여자들이 그것을 처리하길 원할지라도). 그러나 성실한 참여자의 두 번째 최우선 순위는 합의입니다. 이중지불이 가능한 네트워크는 전혀 유용하지 않으므로 성실한 참여자는 정확성 외에는 합의를 가장 중요하게 생각합니다.

컨센서스 라운드(Consensus Rounds)

컨센서스 라운드는 처리할 거래 그룹에 대해 합의하기 위한 시도입니다. 컨센서스 라운드는 참여하고자 하는 각 참여자가 초기 위치를 취하는 것으로 시작됩니다. 이는 참여자들이 본인이 보았던 유효한 거래의 집합입니다.

그런 다음 참여자들은 컨센서스를 위해 "눈사태"를 일으킵니다: 특정 거래가 다수의 지지를 받지 않는다면, 참여자들은 해당 거래를 연기하기로 동의합니다. 특정 거래가 다수의 지지를 받는다면, 참여자들은 해당 거래를 포함하기로 동의합니다. 이렇게 약간의 다수가 빠르게 만장일치 지지로 바뀌고 약간의 소수가 현재 라운드에서 거부됩니다.

컨센서스가 50% 근처에서 정체되는 것을 방지하고 신뢰할 수 있는 수렴에 필요한 겹치기를 줄이기 위해 트랜잭션을 포함하기 위해 필요한 임계치는 시간이 지남에 따라 증가합니다. 처음에는 참여자들이 다수의 동의를 받는 경우에만 거래를 포함하기로 동의합니다. 참여자들이 의견이 분기하는 경우, 임계치를 높여 60% 이상으로 설정하고, 그 이후에도 더 높여서 모든 논쟁 거래를 현재 집합에서 제거합니다. 이렇게 제거된 거래는 다음 ledger 버전으로 연기됩니다.

참여자가 다음 처리될 거래 집합에 대해 지지를 받는 상대 다수를 볼 때, 그들은 합의가 이루어진 것으로 선언합니다.

컨센서스 실패 가능성(Consensus Can Fail)

완벽한 합의를 달성하지 못하는 컨센서스 알고리즘을 개발하는 것은 현실적으로 불가능합니다. 그 이유를 이해하기 위해 컨센서스 프로세스가 어떻게 끝나는지 살펴보겠습니다. 어느 시점에서는 각 참여자가 합의가 이루어졌고 일부 거래 집합이 프로세스의 결과로 알려져 있다고 선언해야 합니다. 이 선언은 해당 참여자가 특정 거래 집합을 합의 프로세스의 결과로서 변경할 수 없음을 의미합니다.

어떤 참여자가 이를 먼저 수행해야만 다른 참여자들도 이를 수행하고 합의에 도달할 수 있습니다. 이제, 이를 먼저 수행하는 참여자는 합의에 도달하지 않을 것입니다. 이 참여자가 합의가 완료되었다고 결정할 때 다른 참여자들은 아직 그 결정을 내린 것이 아닙니다. 만약 다른 참여자들이 그들의 관점에서 합의된 집합을 변경할 수 없다면, 이미 합의가 완료되었다고 결정한 상태일 것입니다. 그러므로 그들은 여전히 합의된 집합을 변경할 수 있는 상태에 있어야 합니다.

다른 말로 하면, 컨센서스 프로세스가 완료되려면 어떤 참여자가 일부 거래 집합이 합의된 것으로 선언하고 다른 참여자들이 이를 변경할 수 있는 상태일 때만 가능합니다.

예를 들어, 문을 나가기 위해 어떤 문을 사용해야 하는지 합의하려는 방에서 사람들의 그룹을 상상해보십시오. 참여자들이 토론을 하더라도, 어느 순간에는 누군가가 첫 번째로 문을 나가기로 결정해야 합니다. 이 참여자가 합의가 완료되었다고 결정할 때, 다른 사람들은 아직 그 결정을 내리지 않았습니다. 그들이 합의된 집합을 변경할 수 없는 상태라면 이미 그들은 합의가 완료되었다고 결정한 것일 테지만, 그들은 여전히 합의된 집합을 변경할 수 있는 상태에 있을 것입니다.

이러한 종류의 실패 가능성은 매우 낮게 만들 수 있지만, 절대로 0으로 줄일 수는 없습니다. 공학적인 트레이드오프로 인해 이 확률을 1,000분의 1 이하로 낮추려면 컨센서스가 현저히 느려지고 네트워크 및 엔드포인트 장애를 용인하기 어려워집니다.

컨센서스 실패 시 XRP Ledger의 처리 방법(How the XRP Ledger Handles Consensus Failure)

컨센서스 라운드가 완료된 후, 각 참여자는 합의된 거래 집합을 적용하여 다음 ledger 상태를 구성합니다.

동시에 검증자로서의 역할을 하는 참여자들은 이 다음 ledger에 대한 암호학적 지문을 발행합니다. 이를 "유효성 투표"라고 합니다. 컨센서스 라운드가 성공한 경우, 성실한 검증자 대부분은 동일한 지문을 발행해야 합니다.

그런 다음 참여자들은 이러한 유효성 투표를 수집합니다. 유효성 투표를 통해 이전 컨센서스 라운드에서 대다수의 참여자들이 거래 집합에 합의했는지 여부를 확인할 수 있습니다.

그 결과, 참여자들은 가능성에 따라 다음 세 가지 상황 중 하나에 속하게 됩니다:

  1. 대다수가 합의한 거래 집합과 동일한 ledger를 구축했습니다. 이 경우 해당 ledger를 완전히 검증되었다고 간주하고 그 내용을 신뢰할 수 있습니다.

  2. 대다수가 합의한 거래 집합과 다른 ledger를 구축했습니다. 이 경우 대다수가 합의한 ledger를 구축하고 수용해야 합니다. 이는 해당 참여자가 일찍 합의를 선언했고 다른 참여자들이 그 후에 변경한 것을 의미합니다. 이들은 수용하기 위해 대다수의 ledger로 "전환"해야 합니다.

  3. 유효성 투표를 통해 대다수가 명확하게 나타나지 않는 경우입니다. 이 경우 이전 컨센서스 라운드는 무산되었으며, 새로운 라운드가 진행되어야만 어떠한 ledger도 검증될 수 있습니다.

물론, 상황 1이 가장 일반적입니다. 상황 2는 네트워크에 아무런 영향을 미치지 않습니다. 소수의 참여자들이 매 라운드마다 상황 2에 해당할 수도 있지만, 네트워크는 아무런 문제없이 작동할 수 있습니다. 실제로 이러한 참여자들은 대다수와 동일한 ledger를 구축하지 않았음을 인지하므로, 대다수와 컨센서스가 이루어질 때까지 자신의 결과를 최종으로 보고하지 않아야 합니다.

상황 3은 네트워크가 몇 초 동안 전진할 수 있는 기회를 잃게 되지만, 매우 드물게 발생합니다. 이 경우, 다음 컨센서스 라운드에서는 의견 분기가 해소되고, 남아 있는 의견 분기만이 실패의 원인이 될 수 있으므로 컨센서스 실패가 더 적게 발생합니다.

드물게 네트워크 전체가 몇 초 동안 전진하지 못하는 경우가 있습니다. 그 대신 평균 거래 확인 시간이 낮습니다.

철학(Philosophy)

신뢰성의 한 형태는 일부 구성 요소가 고장나거나 일부 참여자가 악의적인 상황에서도 시스템이 결과를 제공할 수 있는 능력입니다. 이는 중요하지만, 암호화된 결제 시스템에서 훨씬 더 중요한 신뢰성의 다른 형태는 신뢰할 수 있는 결과를 생성할 수 있는 시스템의 능력입니다. 즉, 시스템이 신뢰할 수 있는 결과로 보고할 때 그 결과에 의존할 수 있어야 합니다.

그러나 실제 시스템은 하드웨어 고장, 통신 장애, 심지어 부정직한 참여자들과 같은 운영 조건에서 두 종류의 신뢰성이 모두 손상될 수 있습니다. XRP Ledger의 설계 철학 중 일부는 결과의 신뢰성이 저하된 상황을 감지하고 보고하는 것이며, 의존해서는 안 되는 결과를 제공하는 대신 이를 강조하는 것입니다.

XRP Ledger의 컨센서스 알고리즘은 계산 리소스를 불필요하게 소모하지 않으면서도 작업 증명 시스템에 대한 견고한 대안을 제공합니다. 비잔틴 오류는 가능하며 발생하지만, 그 결과는 소규모의 지연에 불과합니다. 모든 경우에 XRP Ledger의 컨센서스 알고리즘은 결과가 실제로 신뢰할 수 있는 경우에만 신뢰할 수 있는 결과로 보고합니다.

Previous컨센서스 구조(Consensus Structure)Next공격과 실패 모드에 대한 컨센서스 보호(Consensus Protections Against Attacks and Failure Modes)

Last updated 1 year ago