Technical specifications
AUTH ModuleANATHA NETWORK
System Architecture
아키텍처의 범위는 핵심 블록체인 소프트웨어, 블록체인 인덱서 및 다양한 클라이언트 대면 구성 요소가 핵심 블록체인 및 블록체인 인덱서와 인터페이스하는 JavaScript SDK입니다.
Core Blockchain
ANATHA 블록체인의 핵심 블록체인 부분은 텐더민트 프로토콜을 사용하여 보호되고 코스모스 생태계를 활용하여 자체 ANATHA SDK를 개발하여 구축됩니다. 텐더민트 코어는 합의 엔진 실행 및 P2P 연결 계층 관리를 처리합니다. 따라서 Tendermint는 실행중인 트랜잭션에 대해 아무것도 모릅니다. 트랜잭션 유효성 검사 및 트랜잭션 실행은 모듈이라고하는 별도의 기능 기반 상태 머신에서 ANATHA 네트워크 계층에서 수행됩니다.
DECENTRALIZED HUMAN READABLE ADDRESS MODULE
이 모듈에는 ANATHA 주소를 하나 이상의 탈중앙화 된 사람이 읽을 수 있는 주소 (DeHRA) 및 다중통화 지갑 및 기타 암호화 주소를 포함 할 수 있는 메타데이터에 연결하는 모든 논리가 포함되어 있습니다. 모든 사용자는 여러 DeHRA를 가질 수 있습니다. 모든 DeHRA는 기본 ANATHA 주소를 가리킵니다. 모든 ANATHA 주소는 암호화폐와 동일한 암호화폐 내의 주소 순서로 그룹화된 여러 암호화폐에 대한 주소 매핑을 보유합니다.
사용자는 여러 암호화폐에서 여러 주소를 추가할 수 있습니다. ANATHA 플랫폼 내에서 알려진 암호화폐의 첫 번째 등록 주소는 등록비가 감소합니다. 다음의 모든 등록 주소에는 수수료가 증가합니다. 수수료 메커니즘은 네트워크에 과부하가 걸리는 악의적인 트랜잭션을 줄이기 위해 설정됩니다.
Addresses
ANATHA 네트워크는 사용자가 바이너리 데이터를 처리해야 하는 모든 곳에서 Bech32 주소 형식을 사용합니다. Bech32 인코딩은 데이터에 대한 강력한 무결성 검사를 제공하고 사람이 읽을 수 있는 부분 (HRP)은 UI 개발자가 유익한 오류 메시지를 제공하는 데 도움이 될 수 있는 상황별 힌트를 제공합니다. ANATHA 네트워크에서 키와 주소는 계정, 유효성 검사기 등과 같은 네트워크의 여러 역할을 참조할 수 있습니다.
ANATHA NETWORK MODULES
이 장에서는 제품 문서에 정의된 ANATHA 비즈니스 로직을 실행하는 데 필요한 모듈에 대해 설명합니다. 또한 기존 오픈소스 모듈을 재사용하고 처음부터 빌드하기 위한 노력에 대해서도 논의할 것입니다.
다음 부분으로 구성된 모듈 정의 프레임워크(Module Definition Framework ) 내의 모든 모듈을 제공합니다.
요약-높은 수준의 모듈 목적을 정의합니다.
개념-사양 전체에서 사용되는 전문 개념 및 정의를 설명합니다.
상태-저장되는 데이터 및 데이터 구조의 종류 지정
메시지-모듈 상태 머신이 처리할 수있는 트랜잭션
블록 시작-시작 블록 작업 지정
끝 블록-모든 끝 블록 작업 지정
후크-이 모듈에서 호출할 수 있는 후크를 설명합니다.
Keepers-모듈 기능에 대한 논리적 구분. Keeper methods는 핸들러 함수에서만 호출됩니다.
이벤트-인덱싱을 위해 내보냅니다. 이벤트에는 모듈에서 방출되는 유형과 키 및 값이 포함됩니다.
매개 변수-각 모듈의 구성 지점
목록은 구속력이 없으며 모든 부분은 선택 사항입니다.
AUTH Module
Abstract
인증 모듈은 애플리케이션에 대한 기본 트랜잭션 및 계정 유형을 지정합니다. 여기에는 모든 기본 트랜잭션 유효성 검사 (서명, 논스, 보조 필드)가 수행되는 ante 핸들러가 포함되어 있으며 다른 모듈이 계정을 읽고, 쓰고, 수정할 수 있도록 하는 계정 키퍼를 노출합니다.
State
계정에는 재생 보호를 위해 공개키, 주소 및 계정 번호 / 시퀀스 번호를 포함하여 SDK 블록체인의 고유하게 식별된 외부 사용자에 대한 인증 정보가 포함됩니다. 효율성과 수수료 지불을 위해 계정 잔액도 가져와야 함으로 계정 구조는 사용자의 잔액도 저장합니다.
Messages
auth 모듈에는 자체 트랜잭션 핸들러가 없지만 트랜잭션에 대한 기본 유효성 검사를 수행하는 데 사용되는 AnteHandler라는 특수 핸들러를 노출하여 mempool에서 버릴 수 있습니다. ante 핸들러는 CheckTx에서 호출되지만 DeliverTx에서도 호출됩니다.
AnteHandler는 구성 가능하며 추가 검사 미들웨어를 추가 할 수 있습니다. 처음에 AnteHandler는 다음 검사를 수행합니다.
거래 유형-알려진 거래 유형 만 허용
거래 서명 확인
수수료 금액 확인
Keepers
auth 모듈은 계정을 읽고 쓰는 데 사용할 수 있는 하나의 키퍼 AccountKeeper 만 노출합니다. 또한 응답 공격 보호를 위한 유틸리티 기능을 제공합니다. 키퍼는 다음 메소드를 노출합니다.
지정된 주소로 계정 개체 생성
연속 계정 번호로 계정 개체 생성
스토어에서 계정 검색
스토어에 계정 유지
스토어에서 계정 제거
모든 계정을 통한 반복
주소를 기반으로 계정 공개키 검색
주소를 기반으로 계정의 순서를 검색합니다.
다음 글로벌 계정 번호 받기
Parameters
인증 모듈은 다음 구성을 제공합니다.
트랜잭션에 메모로 첨부할 수 있는 최대 데이터 양입니다. 메모를 사용하여 오프 체인 처리를 호출할 수 있습니다.
단일 트랜잭션에 포함될 수 있는 서명의 한계
서명 확인의 크기와 비용에 따라 결정되는 거래 수수료 메커니즘.
Advanced Tx Module
Abstract
Tx 모듈은 계정 간의 코인 이체를 처리하고 특정 종류의 계정에서 다르게 작동해야 하는 특수 사례인 유사- 이체를 추적합니다 (특히 저축 계정의 본딩 / 언 본딩). 사용자 밸런스를 변경해야 하는 다른 모듈과의 안전한 상호 작용을 위해 다양한 기능을 가진 여러 인터페이스를 노출합니다.
State
현재 Tx 모듈에는 고유한 상태가 없습니다. 인증 모듈에서 AccountKeeper를 사용하여 계정을 읽고 씁니다. 이 구현( implementation) 선택은 대부분의 거래에 코인 금액 (수수료)이 포함될 것으로 예상되므로 필요한 상태 읽기 / 쓰기를 최소화하기 위한 것이므로 계정에 코인 데이터를 저장하면 별도로 읽는 것이 절약됩니다.
Keepers
Tx 모듈은 계정 잔액을 읽거나 업데이트해야 하는 다른 모듈로 전달할 수 있는 세 가지 내보낸 키퍼 인터페이스를 제공합니다.
BaseKeeper-모든 계정의 잔액을 임의로 수정하고 코인을 주조하거나 태울 수 있는 전체 권한 액세스를 제공합니다.
setCoins-주소로 계정을 가져오고, 계정에 코인을 설정하고, 계정을 저장합니다.
addCoins / subtractCoins-계정의 코인을 가져오고 제공된 금액을 더하거나 빼고 계정을 저장합니다. 이것은 총 공급을 증가 / 감소시킵니다.
SendKeeper-계정 잔액에 대한 액세스와 계정간에 코인을 이체 할 수있는 기능을 제공하지만 총 공급량은 변경하지 않습니다.
sendCoins-한 계정에서 다른 계정으로 코인을 전송합니다.
ViewKeeper-계정 잔액에 대한 읽기 전용 액세스를 제공하지만 잔액 변경 기능은 제공하지 않습니다. 모든 균형 조회는 일정한 시간 및 공간 복잡성으로 수행됩니다.
getCoins-계정과 관련된 코인을 반환합니다.
hasCoins-계정에 최소한 제공된 양의 코인이 있는지 여부를 반환합니다.
Messages
Tx 모듈은 여러 송금 잔액을 여러 수신 계정으로 이체하는 것을 지원하는 MsgSend 유형의 트랜잭션 하나만 처리합니다.
Events
뱅크 모듈에서 다음 이벤트가 생성됩니다.
유형 : 전송, 키 : 수신자, 값 : <주소>
유형 : 이체, 키 : 금액, 값 : <금액>
유형 : 메시지, 키 : 모듈, 값 : 뱅크
유형 : 메시지, 키 : 작업, 값 : 보내기
유형 : 메시지, 키 : 보낸 사람, 값 : <주소>
Parameters
Tx 모듈은 다음 구성을 제공합니다.
토큰 전송 기능 사용 여부입니다. 이는 모든 전송이 잠긴 합의 프로토콜 테스트 단계에 사용됩니다.
DISTRIBUTION Module
Abstract
이 배포 모듈은 네트워크 참여자간에 보상을 수동적으로 분배하는 기능적 방법을 구현합니다. 계산 최적화를 위해 이 메커니즘은 자금을 사전에 분배하지 않고 사용자가 보상을 청구할 수 있도록 합니다.
Concepts
배포 모듈은 모듈 또는 모듈 계정이될 수 있는 여러 풀로 구성됩니다. 전체 배포 메커니즘은 아래 다이어그램에 나와 있으며 다음으로 구성됩니다.
인플레이션 분배-모든 블록에서 생성되는 연간 인플레이션 1 %는 Mint 모듈에서 전송되어 Anatha 마스터 모듈 및 네트워크 검증자 보상 풀에 할당됩니다.
네트워크 검증 보상 풀은 저축 계정 모듈에서 계산된 보상 금액을 고정하고 나머지는 이전 블록에서 얻은 보상에 대해 다음 블록에 분배합니다. 저축 풀에 대한 아웃바운드 분배는 다음과 같이 계산됩니다.
Savings Accounts 모듈은 최소 24 시간 동안 담보를 잠근 모든 세이버에게 24 시간마다 한 번씩 분배를 활성화합니다.
Anatha Master Modules의 분배 기능은 매일 한 번 실행되며 다음과 같은 방법으로 자금을 분배합니다.
분배의 50 %는 지난 24 시간 동안 HRA 소유자였던 HRA 보유자간에 분할됩니다. 계정 당 하나의 HRA 만 보상을받을 수 있습니다.
배포 수수료의 25 %가 Anatha Development Fund 계정으로 이체됩니다.
분배의 25 %는 보유하고 있는 보안 토큰의 양에 비례하여 보안 토큰 보유자간에 분할됩니다.
언급된 모든 코인 분배는 사전에 수행되지 않고 사용자가 자신의 계정에 대한 인출을 호출하는 거래를 보내기로 결정할 때까지 예약됩니다.
Anatha Master Module은 블록체인 실행의 첫 365 일 동안 상금 인출을 차단합니다.
Messages
배포 모듈은 다음 메시지를 처리합니다.
MsgWithdrawValidatorRewardsAll-검증인이 보상을 철회하려면 MsgWithdrawValidatorRewardsAll을 보내야 합니다. 이 거래는 검증인의 보상과 자기지분으로 얻은 보상을 철회합니다. 이 트랜잭션 논리의 일부는 결합 해제와 같은 개별 위임의 변경으로 인해 각각 촉발됩니다.
CRISIS Module
Abstract
위기 모듈은 블록체인 불변이 깨지는 상황에서 블록체인을 중지합니다.
Concepts
응용 프로그램 초기화 프로세스 중에 고정 항목을 응용 프로그램에 등록할 수 있습니다. 각 모듈은 경로를 포함하여 위기 모듈에 불변성을 노출할 수 있습니다. 불변은 한 번에 하나씩 확인할 수 있으며 거래 수수료 지불이 필요합니다.
불변 (및 최대 허용 블록 가스 제한을 초과할 가능성이 있음)을 확인하는 데 필요한 큰 가스 비용으로 인해 표준 가스 소비 방법 대신 일정한 요금이 사용됩니다. 고정 요금은 표준 가스 소비 방법으로 불변을 실행하는 데 예상되는 가스 비용보다 더 큰 금액입니다.
Messages
블록체인 불변은 검사할 정확한 불변을 지정하는 MsgVerifyInvariant 메시지를 사용하여 확인할 수 있습니다. 이 메시지는 발신자에게 일정한 수수료에 대한 코인이 충분하지 않거나 불변 경로가 등록되지 않은 경우 실패할 것으로 예상됩니다. 이 메시지는 제공된 불변을 확인하고 불변이 깨지면 패닉을 일으키고 블록 체인을 중지합니다. 불변성이 깨지면 거래가 블록에 커밋되지 않으므로 (환불되는 것과 동일) 상수 수수료가 공제되지 않습니다. 단, 불변이 깨지지 않으면 불변 요금은 환불되지 않습니다.
Events
위기 모듈에서 다음 이벤트가 생성됩니다.
유형 : 고정, 키 : 경로, 값 : <경로>
유형 : 메시지, 키 : 모듈, 값 : 위기
유형 : 메시지, 키 : 작업, 값 : verify_invariant
유형 : 메시지, 키 : 보낸 사람, 값 : <주소>
Parameters
ConstantFee 매개변수는 글로벌 매개변수 저장소에 보관됩니다.
GOVERNANCE Module
Abstract
거버넌스 모듈을 사용하면 블록체인이 온- 체인 거버넌스 시스템을 지원할 수 있습니다. 분산 형 거버넌스 시스템으로 발전하기 전에 이 모듈은 임계값 온체인 다중 서명모델을 기반으로 거버넌스 절차를 구현합니다. 즉, 제네시스 블록에 등록된 참가자만 거버넌스 제안 및 투표를 생성할 수 있습니다. 업그레이드 모듈의 메커니즘을 활용하여 거버넌스 모듈을 분산 거버넌스로 자동 업데이트할 수 있습니다. (이 거버넌스 모듈이 구축되는 동안 ANATHA 마스터 계약 (소프트 런칭 후 12 개월)의 첫 번째 글로벌 배포 후에 작동하며 노드 운영자의 규정 준수를 요구하는 네트워크 업그레이드를 통해 수행될 것입니다. 몇 달 동안 소프트 런칭 후 거버넌스는 재무 계정에 대한 제어권을 할당하고 노드 소프트웨어 업데이트를 제안합니다.)
Concepts
거버넌스 프로세스는 다음과 같은 몇 가지 단계로 나뉩니다.
제안 제출 : 제안은 사전에 정의된 거버넌스 관리자 중 한 명이 블록체인에 제출합니다.
투표 : 제안서가 제출되면 투표가 열립니다. 사전 정의된 다른 거버넌스 관리자는 제안에 투표하기 위해 TxGovVote 트랜잭션을 보낼 수 있습니다.
제안에 소프트웨어 업그레이드가 포함된 경우 :
신호 : 유효성 검사기는 새 버전으로 전환할 준비가 되었음을 알리기 시작합니다.
전환 : 검증자의 75 % 이상이 전환할 준비가 되었다고 신호를 보내면 소프트웨어가 자동으로 새 버전으로 전환됩니다.
거버넌스 모듈의 초기 버전에는 두 가지 유형의 제안이 있습니다.
PlainTextProposal-소스 코드의 수정을 포함하지 않는 모든 제안은 이 유형에 속합니다. 예를 들어, 여론 조사는 PlainTextProposal 유형의 제안을 사용합니다.
SoftwareUpgradeProposal-수락되면 검증인은 제안에 따라 소프트웨어를 업데이트 해야합니다. 이 메커니즘은 업그레이드 모듈에 설명되어 있습니다.
다른 모듈에 노출된 제안 핸들러 및 유형
다른 모듈은 자체 제안 유형 및 핸들러를 구현하여 거버넌스 모듈을 확장할 수 있습니다. 이러한 유형은 거버넌스 모듈 (예 : ParamChangeProposal, TreasuryProposal, SofwareUpgradeProposal)을 통해 등록 및 처리되며 제안이 통과되면 각 모듈의 제안 핸들러를 실행합니다. 이 특수한 핸들러는 임의의 상태 변경을 수행할 수 있습니다.
초기 옵션 세트에는 Yes, No, NoWithVeto, Abstain 옵션이 포함됩니다. NoWithVeto는 아니요로 간주되지만 거부권도 추가됩니다. 기권 옵션을 사용하면 유권자가 제안에 찬성 또는 반대 투표를 하지 않고 투표 결과를 수락한다는 신호를 보낼 수 있습니다.
쿼럼은 결과가 유효하기 위해 제안서에 캐스팅되어야 하는 투표권의 최소 비율로 정의됩니다. 임계값은 제안이 수락될 수 있는 찬성 투표 (기권 투표 제외)의 최소 비율로 정의됩니다.
처음에 임계값은 투표의 1/3 이상 (기권 투표 제외)이 NoWithVeto 투표인 경우 거부할 수 있는 50 %로 설정됩니다. 즉, 투표 기간이 끝날 때 찬성 투표 (기권 투표 제외) 비율이 50 %보다 높고 NoWithVeto 투표 비율이 1/3 이하 (기권 투표 제외) 인 경우 제안이 수락됩니다.
State
거버넌스 모듈이 사용하는 주요 데이터 구조는 다음과 같습니다.
매핑 맵 [proposalID]-> Proposal. 제안 유형은 콘텐츠, ID, 상태, 결과 및 다양한 타임 스탬프와 같은 제안에 대한 기본 정보를 저장합니다.
투표에 대한 매핑 맵 [proposalID] [address]. 이 매핑을 통해 제안서에 투표한 모든 주소를 투표와 함께 쿼리할 수 있습니다.
Messages
거버넌스 모듈이 처리하는 메시지는 다음과 같습니다.
TxGovSubmitProposal-제안 제출
TxGovVote-투표 거래
MINTING Module
Abstract
채굴 메커니즘은 시스템에서 인플레이션 율을 생성하도록 설계되었습니다. 인플레이션 율은 초기에 매년 1 %로 설정되며 매일 (또는 블록 당) 계산됩니다. 이 모듈은 여러 매개변수를 기반으로 동적 인플레이션 율을 지원하지만 거버넌스 제안 또는 네트워크 업그레이드 절차를 통해 변경할 수있 는 고정된 1 % 연간 인플레이션 율로 시작합니다.
State
채굴 모듈 상태는 두 개의 다른 저장소로 구성됩니다.
모듈레벨 저장소-현재 연간 인플레이션 율과 현재 연간 예상 공급량을 유지합니다. 이 값은 네트워크에서 수락한 이전 블록의 모든 블록에서 업데이트됩니다.
글로벌 매개변수 저장소-거버넌스 제안을 통해 변경할 수 있는 매개변수입니다. 매개변수 섹션에 설명
Begin Block
채굴 매개변수가 재계산되고 이전에 처리된 블록의 각 블록 시작시 인플레이션이 지불됩니다.
목표 연간 인플레이션율은 각 블록에서 다시 계산됩니다. 구성된 경우 인플레이션은 원하는 지분 / 저축 비율과의 거리에 따라 비율 변경 (양수 또는 음수)의 영향을 받습니다. 연간 최대 인플레이션 변경은 독립적으로 설정할 수 있으며 연간 인플레이션의 최대 값과 최소 값도 설정할 수 있습니다.
연간 공급량은 현재 총 공급량과 인플레이션율을 기준으로 다음 공식을 사용하여 각 블록에서 계산됩니다.
블록 규정은 현재 연간 규정을 기반으로 각 블록에 대해 생성됩니다. 그런 후 조항은 민트 모듈의 ModuleMinterAccount에 의해 생성된 다음 인증의 FeeCollector 모듈 계정으로 전송됩니다. 블록 규정은 다음 공식으로 계산됩니다.
Parameters
글로벌 매개변수 저장소에 저장되는 Minting 모듈의 구성 가능한 매개변수 :
MintDenom-주조할 코인 유형
InflationRateChange-인플레이션율의 최대 연간 변동
InflationMax-최대 인플레이션율
InflationMin-최소 인플레이션율
GoalBonded-보세 자산 비율의 목표
BlocksPerYear-연간 예상 블록입니다. 블록체인의 시간 기반 계산에는 사용되지 않지만 예상 블록 프로비저닝을 계산하는 데만 사용됩니다.
참고 : 1 %의 연간 인플레이션율을 일정하게 유지하려면 InflationMax 및 InflationMin 매개변수를 모두 1 %로 설정해야 합니다.
Events
위기 모듈에서 다음 이벤트가 생성됩니다.
유형 : mint, 키 : bonded_ratio, 값 : <bonded_ratio>
유형 : 민트, 키 : 인플레이션, 값 : <인플레이션>
유형 : 민트, 키 : Annual_provisions, 값 : <annual_provisions>
유형 : 민트, 키 : 금액, 값 : <금액>
PARAMS Module
Abstract
params 모듈은 다양한 모듈을 구성하는 데 사용할 수 있는 전반적으로 사용 가능한 매개변수 저장소를 제공합니다. 허가된 매개변수 저장소 액세스를 지원할 수 있습니다.
Concepts
매개 변수 저장소에는 두 가지 주요 유형이 있습니다.
Keeper Parameter Store-모든 기존 공간에 액세스 할 수있는 권한이 있습니다. 모듈에서 사용하려면 해당 모듈을 초기화하는 동안 주입해야 합니다.
부분 공간-매개 변수 저장을 위한 격리된 네임 스페이스. 여기서 키는 미리 구성된 공간 이름으로 시작됩니다. 다른 키퍼가 수정할 수 없는 개인 매개 변수 저장소가 필요한 다른 모듈에서 부분 공간을 사용할 수 있습니다.
REWARDS/STAKING MODULE
Abstract
이 모듈을 통해 블록체인은 지분 증명 시스템을 지원할 수 있습니다. 이 시스템에서 체인의 네이티브 스테이킹 토큰 보유자는 최종적으로 시스템에 대한 효과적인 검증자 세트를 결정하기 위해 검증자 및 스테이크 토큰이될 수 있습니다. 다른 PoS 네트워크 간의 구체적인 차이점은 이 시스템에서 모든 검증자가 지분과 동일한 투표권을 갖게된다는 것입니다. 이 메커니즘은 HRA 보유자 만 사용할 수 있습니다.
보상 모듈을 통해 사용자는 담보를 잠그고 24 시간 동안 이자를 받을 수 있습니다. 보상 모듈은 자금을 예치한 계정 목록을 저장합니다. Dev Ojha가 제안한 온체인 수수료 분배 모듈을 실행하기 위한 데이터 구조를 저장합니다. 보상 자금은 배포 모듈에 설명된 Network Validator 보상풀에서 이체됩니다.
Concepts
Anatha 유효성 검사기는 다음 세 가지 상태중 하나일 수 있습니다.
Unbonded-유효성 검사기가 활성 세트에 없습니다. 블록에 서명할 수 없고 보상도 얻지 못합니다.
Bonded-검증자가 충분한 본딩 토큰을 스테이킹하면 EndBlock 중에 자동으로 활성 세트에 가입하고 상태가 Bonded로 업데이트됩니다. 그들은 블록에 서명하고 보상을 받고 있습니다. 그들은 잘못된 행동으로 인해 제거될 수 있습니다. Validator가 Validating을 중지하려면 이를 알리고 체인별 매개변수인 UnbondingTime 기간 동안 기다려야 합니다. 이 시간 동안 토큰이 결합된 기간 동안 범죄가 저질러졌다면 범죄에 대해 여전히 깎을 수 있습니다.
Unbonding-검증자가 선택이나 슬래싱 또는 툼스토닝으로 인해 활성세트를 떠날 때, 지분의 언본딩이 시작되고 BondedPool에서 토큰이 전송되기 전에 지정된 UnboundingTime 동안 지속됩니다.
현재 스테이킹 구현에는 다음과 같은 중요한 개념이 있습니다.
운영자-검증인을 운영하고 토큰을 스테이킹한 엔티티를 나타내는 키페어
유효성 검사기-합의에 참여하는 키페어. 한 운영자가 유효성 검사기 키를 변경할 수 있습니다. 이것이 Tendermint가 보는 것입니다.
검증 세트는 검증 세트에 있었던 시간을 기준으로 정렬되는 최상위 MaxValidator로 구성됩니다. 이 세트는 자주 변경되지 않으므로 대기중인 검증인에게 인센티브를 제공합니다.
Messages
스테이킹 모듈은 다음 메시지를 처리합니다.
MsgCreateValidator-블록체인에 새로운 잠재적 검증인을 알리는 메시지에는 스테이킹될 사전 정의된 양의 MinSelfDelegation 코인이 포함되어야 합니다.
MsgEditValidator-유효성 검사기 정보를 주소, 설명으로 변경할 수 있습니다.
MsgBeginUnbonding-검증자가 더 이상 합의 알고리즘에 참여하기를 원하지 않음을 네트워크에 알립니다. 검증자는 지분을 돌려받기 전에 UnbondingTime을 기다려야합니다.
End Block
End Block 이벤트에서 몇 가지 중요한 변경 사항이 발생합니다.
스테이킹 검증자 세트는이 과정에서 업데이트됩니다. 이 프로세스의 일부로 업데이트된 검증자는 합의 계층에서 텐더민트 메시지를 검증하는 책임이 있는 텐더민트 검증인 세트에 포함하기 위해 텐더민트로 다시 반환됩니다. 새로운 유효성 검사기 세트는 전원별로 정렬된 상위 MaxValidator로 구성됩니다. 해당 검증인 세트는 이전 검증인 세트와 비교되고 누락된 모든 검증인은 토큰의 본딩을 해제하기 시작하고 새로운 검증인은 즉시 결합됩니다. 모든 토큰 전송은 NotBondedPool과 BondedPool간에 수행됩니다.
검증인이 본딩된 검증인 세트를 떠날 때 (갇혀있거나 충분한 본딩된 토큰이 없는 경우) 언본딩 프로세스를 시작합니다. 이 시점에서 검증자는 Unbonding 검증자라고 말하며 UnbondingTime 기간이 지나면 "Unbonded Validator"로 성숙해집니다. 유효성 검사기 대기열의 각 블록은 성숙한 언본딩 유효성 검사기를 확인해야 합니다. 이 시점에서 모든 만기된 유효성 검사기는 삭제됩니다.
Parameters
스테이킹 모듈은 다음 매개변수를 제공합니다.
MinSelfDelegation-모든 검증인이 투자해야 하는 지분의 양, 정확한 숫자여야 합니다.
UnbondingTime-검증 중지를 결정한 후 검증인의 담보를 잠금 해제하는 데 필요한 시간
MaxValidators-단일 합의 라운드에서 허용되는 최대 검증자 수
BondDenom-글로벌 스테이킹 통화의 명칭
SLASHING Module
Abstract
슬래싱 모듈은 가치가 있는 프로토콜 인식 행위자의 기여 가능한 행동을 페널티( "슬래싱")함으로써 인센티브를 떨어뜨립니다. 벌칙에는 다음이 포함됩니다.
지분의 일부를 소각
일정 기간 동안 향후 블록에 대한 투표 능력 제거
Concepts
주어진 시간에서 상태 머신에 등록된 검증인이 얼마든지 있습니다. 구속되지 않은 각 블록, 상위 MaxValidators 검증인은 결합되어 블록을 제안하고 투표할 수 있습니다. 결합된 검증인은 위태 롭습니다. 즉, 프로토콜 오류를 범할 경우 지분의 일부 또는 전부가 위험에 처해 있습니다.
슬래싱 모듈이 처리하는 프로토콜 오류는 다음과 같습니다.
이중블록 표지판 (Equivocation)
Liveness 결함-Validator는 자동으로 구속되고, 슬래시를 당하고, 결합 해제됨으로써 일부 블록에 대한 프리커밋 목록에 포함되지 않은 경우 벌칙을 받습니다.
슬래싱 모듈은 모든 슬래싱 위반 처벌의 글로벌 저장소를 유지하지만 더 가벼운 위반이므로 Liveness 결함만 처리하고 더 심각한 합의 위반은 증거 모듈에서 처리합니다.
라이브니스 슬래싱은 위반이 발생되는 즉시 감지되므로 추가 위반 증명을 받기 위해 슬래싱 기간이 필요하지 않습니다. 검증인은 즉시 감옥에 갇히게되며 탈옥되지 않는 트랜잭션을 보낼 때까지 다른 활성 오류를 저지를 수 없습니다.
State
모든 블록에는 Tendermint에서 제공하는 LastCommitInfo인 이전 블록에 대한 유효성 검사기의 프리커밋 세트가 포함됩니다. LastCommitInfo는 총 투표권의 +2/3에서 프리커밋을 포함하는 한 유효합니다. ValidatorSigningInfo를 통해 검증인의 활성 활동에 대한 정보를 추적합니다. 다음과 같이 스토어에서 색인화됩니다.
ValidatorSigningInfo는 합의 주소가되는 키와 함께 맵에 저장됩니다.
MissedBlocksBitArray는 컨센서스 주소가되는 키와 비트 배열을 나타내는 값으로 맵에 저장되며, 유효성 검사기가 비트 배열에서 주어진 인덱스에 대한 블록을 놓친 경우 각 비트를 나타냅니다.
ValidatorSigningInfo 구조는 다음을 추적합니다.
주소-검증인의 합의 주소입니다.
StartHeight-후보자가 활성 검증자가된 높이입니다 (투표력이 0이 아닌 경우).
IndexOffset-유효성 검사기가 블록에 결합될 때마다 증가하는 인덱스이며 프리커밋에 서명했는지 여부
JailedUntil-활성 중단 시간으로 인해 검증인이 구속되는 시간
Tombstoned: 유효성 검사기가 삭제 표시되는지 여부를 설명합니다. 유효성 검사기가 모호를 커밋하거나 기타 구성된 오작동에 대해 설정됩니다.
MissedBlocksCounter : 불필요한 배열 읽기를 방지하기 위해 유지되는 카운터입니다. Sum (MissedBlocksBitArray)은 항상 MissedBlocksCounter와 같습니다.
Messages
Slashing 모듈은 다음 메시지를 처리합니다.
Unjail-다운타임으로 인해 검증인이 자동으로 본딩 해제되어 온라인 상태로 돌아와서 본드 세트에 다시 참여하고자 하는 경우. 검증인이 상위 MaximumBondedValidators가 될만큼 충분한 지분을 보유하고있는 경우 자동으로 재결합되고 다시 보상을 받기 시작합니다.
Begin Block
각 블록의 시작 부분에서 각 유효성 검사기의 ValidatorSigningInfo를 업데이트하고 슬라이딩 창을 통해 활성 임계값 아래로 넘어갔는지 확인합니다. 이 슬라이딩 창은 SignedBlocksWindow에 의해 정의되며 이 창의 색인은 유효성 검사기의 ValidatorSigningInfo에 있는 IndexOffset에 의해 결정됩니다. 처리된 각 블록에 대해 IndexOffset은 유효성 검사기의 서명 여부에 관계없이 증가합니다. 인덱스가 결정되면 MissedBlocksBitArray 및 MissedBlocksCounter가 그에 따라 업데이트됩니다.
마지막으로 유효성 검사기가 활성 임계값 아래로 교차하는지 확인하기 위해 누락된 최대 블록 수를 가져옵니다.
활성 상태를 결정할 수 있는 최소 높이인 minHeight입니다. 현재 블록이 minHeight보다 크고 유효성 검사기의 MissedBlocksCounter가 MaxMissed보다 큰 경우 SlashFractionDowntime에 의해 슬래시되고 DowntimeJailDuration에 대한 감옥에 갇히고 MissedBlocksBitArray, MissedBlocksCounter 및 IndexOffset 값이 재설정됩니다.
Parameters
Slashing 모듈은 다음과 같은 구성 가능한 매개변수를 제공합니다.
SignedBlocksWindow
MinSignedPerWindow
DowntimeJailDuration
SlashFractionDoubleSign
SlashFractionDowntime
참고 : 설명이 없는 매개변수는 블록시작 장에 설명되어 있습니다.
EVIDENCE Module
Abstract
Evidence 모듈을 사용하면 모호 및 거짓 서명과 같은 잘못된 행동의 임의 증거를 제출하고 처리할 수 있습니다.
Concepts
이 모듈은 다른 모듈이 Crisis 모듈과 유사한 증거 확인 로직을 등록할 수 있도록 API를 제공합니다. 제출된 증거는 먼저 증거 모듈의 라우터를 통해 경로가 설정되며, 여기에서 해당 특정 증거 유형에 해당하는 등록된 핸들러를 찾습니다. 각 증거 유형이 성공적으로 라우팅되고 실행되려면 증거 모듈의 키퍼에 등록된 핸들러가 있어야 합니다. 주어진 증거 유형에 대한 핸들러는 제거, 구속 및 삭제 표시와 같은 임의의 상태전환을 수행할 수 있습니다.
State
현재 Evidence 모듈은 state에서 유효한 제출된 Evidence 목록 만 저장합니다..
Messages
증거는 MsgSubmitEvidence 메시지를 통해 제출됩니다. 메시지에 제공된 증거는 올바르게 처리되고 라우팅되기 위해 증거 모듈의 라우터에 등록된 해당 핸들러가 있어야합니다.
Begin Block
애플리케이션레벨 증거 처리를 위한 일반화된 프레임워크와는 별도로 Evidence 모듈은 발견되면 자동으로 제출되는 기본 합의 엔진을 위한 내장 증거 핸들러를 제공합니다. 관련 정보는 abci.RequestBeginBlock의 ABCI Evidence로 애플리케이션에 전달되어 그에 따라 유효성 검사기가 처벌받을 수 있습니다.
현재 증거 모듈은 BeginBlock 동안 Tendermint의 ABCIEvidenceTypeDuplicateVote에서 파생된 Equivocation (이중 서명) 유형의 증거 만 처리합니다.
유효한 Equivocation 증거가 블록에 포함된 경우, 검증인의 지분은 SlashFractionDoubleSign에 의해 삭감됩니다. SlashFractionDoubleSign은 위반이 발생했을 때의 지분 (증거가 발견되었을 때가 아니라)이 무엇이었는지에 대해 슬래싱 모듈에 의해 정의됩니다. 해당 검증자가 검증인 세트에 다시 들어갈 수 없도록 영구적으로 투옥되고 삭제표시됩니다. 지정된 MaxEvidenceAge보다 오래되지 않은 증거만 고려됩니다.
Parameters
매개변수 증거 모듈에는 다음 매개변수가 포함됩니다.
MaxEvidenceAge-매개변수보다 오래된 증거는 고려되지 않습니다.
SUPPLY Module
Abstract
공급 모듈은 체인 내의 총 코인 공급을 수동적으로 추적하고, 다른 모듈이 코인과 상호 작용할 수 있는 패턴을 제공하고, 체인의 총 공급을 확인하기 위해 보안 불변 검사를 도입합니다.
Concepts
네트워크의 총 공급량은 모든 계정의 모든 코인의 합계와 같습니다. 총 공급량은 코인이 발행되거나 소각될 때마다 업데이트됩니다.
공급 모듈은 모듈이 토큰을 할당하고 특별한 경우 토큰을 발행하거나 소각하는 데 사용할 수 있는 새로운 유형의 계정 (ModuleAccount)을 도입합니다. 기본 수준에서 이러한 모듈 계정은 계정 및 기타 모듈 계정과 토큰을 주고받을 수 있습니다.
각 ModuleAccount에는 특정 작업을 수행하기 위해 서로 다른 개체 기능을 제공하는 서로 다른 권한 집합이 있습니다. ModuleAccount가 허용된 기능을 호출할 때마다 키퍼가 해당 특정 계정에 대한 권한을 조회하고 작업을 수행하거나 수행하지않을 수 있도록 SupplyKeeper 생성시 권한을 등록해야 합니다.
State
공급 모듈 저장소는 체인의 총 공급만 추적합니다. Keepers
공급 키퍼는 다음을 수행할 수 있도록 ModuleAccounts와 관련된 AuthKeeper 및 BankKeeper에 대한 래퍼 기능을 제공합니다.
이름을 제공하여 ModuleAccounts 가져오기 및 설정
이름을 전달하여 다른 ModuleAccounts 또는 표준 계정과 코인을 주고받습니다.
ModuleAccounts에서 동전을 주조하거나 태우십시오.
UPGRADE Module
Abstract
업그레이드 모듈을 사용하면 라이브 체인을 새로운(획기적인) 소프트웨어 버전으로 원활하게 업그레이드할 수 있습니다. 사전 정의된 업그레이드 블록 시간 또는 높이에 도달하면 블록체인 상태 머신이 진행되는 것을 방지하는 BeginBlocker 후크를 제공하여 이를 수행합니다. 안전하게 업그레이드 하십시오. 업그레이드에 대한 소프트웨어 지원이 없으면 모든 유효성 검사기가 프로세스의 정확히 동일한 지점에서 상태 머신을 일시 중지해야하므로 라이브 체인을 업그레이드하는 것은 위험합니다. 이것이 올바르게 수행되지 않으면 복구하기 어려운 상태 불일치가 있을 수 있습니다.
Concepts
업그레이드 모듈은 라이브 업그레이드가 발생하도록 예약된 계획 유형을 정의합니다. 계획은 특정 블록 높이 또는 시간으로 예약할 수 있지만 둘다는 아닙니다. 적절한 업그레이드 핸들러와 함께 (고정 된) 릴리스 후보가 합의되면 계획이 작성됩니다. 여기서 계획의 이름은 특정 핸들러에 해당합니다. 일반적으로 계획은 SoftwareUpgradeProposal 거버넌스 제안 프로세스를 통해 생성되며 투표를 통해 통과되면 일정이 잡힙니다. 플랜 정보에는 업그레이드에 대한 다양한 메타데이터가 포함될 수 있으며, 일반적으로 유효성 검사기가 자동으로 업그레이드할 수있는 git 커밋과 같이 온체인에 포함될 애플리케이션별 업그레이드 정보가 포함될 수 있습니다. 업그레이드 프로세스는 노드 운영자를 위해 완전히 자동화될 수 있습니다. 정보 필드를 필요한 정보로 채우면 바이너리를 자동으로 다운로드할 수 있습니다.
State
업그레이드 모듈의 내부 상태는 상대적으로 최소화되고 간단합니다. 상태는 키 0x0에 의해 현재 활성화된 업그레이드 계획 (있는 경우)과 키 0x1에 의해 "완료"로 표시된 경우에만 포함됩니다.
Messages
이 모듈에 메시지를 전달하는 경로는 업그레이드 계획을 시작하는 유일한 방법인 거버넌스 모듈로만 전달됩니다.
거버넌스 모듈에서 다음 메시지를 사용할 수 있습니다.
SoftwareUpgradeProposal
CancelSoftwareUpgradeProposal
SAVINGS Module
Abstract
Savings 모듈을 통해 사용자는 담보를 잠그고 24 시간 내에 이자를 받을 수 있습니다.
State
저축 모듈은 자금을 예치한 계정 목록을 저장합니다. Dev Ojha가 제안한 온체인 수수료 분배 모듈을 https://drops.dagstuhl.de/opus/volltexte/2019/11400/에 실행하기 위한 데이터 구조를 저장합니다. 저축 자금은 배포 모듈에 설명된 Network Validator 보상풀에서 이체됩니다.
Messages
Savings 모듈은 다음 메시지를 처리합니다.
MsgDeposit-사용자가 자신의 계정에 사용가능한 자금의 25 % 이상을 입금할 수 없습니다.
MsgWithdraw-사용자가 저축 계좌에서 지정된 금액을 인출할 수 있습니다. 이 작업은 저축 차단 시간을 재설정하고 주어진 저축 계좌를 24 시간 이상 터치하지않은 이자 지급 기간에 이자 누적을 시작합니다.
MsgWithdrawInterest-사용자가 자신의 계정으로 이자를 인출할 수 있습니다.
Parameters
저축 모듈에는 거버넌스에 의해 변경될 수 있는 구성 가능한 이자율이 포함됩니다.
HRA - NAME Module
Abstract
이 모듈에는 Anatha 주소를 하나 이상의 사람이 읽을 수 있는 주소 (HRA) 및 해당 메타데이터에 연결하는 모든 논리가 포함되며 여기에는 다중통화 지갑 및 기타 암호화 주소가 포함될 수 있습니다.
Concept
모든 사용자는 여러 HRA를 가질 수 있습니다. 모든 HRA는 기본 Anatha 주소를 가리킵니다. 모든 Anatha 주소는 암호화폐와 동일한 암호화폐 내의 주소 순서로 그룹화된 여러 암호화폐에 대한 주소 매핑을 보유합니다. 사용자는 여러 암호화폐에서 여러 주소를 추가할 수 있습니다. Anatha 플랫폼 내에서 알려진 암호화폐의 첫 번째 등록 주소는 등록 수수료가 감소합니다. 다음의 모든 등록 주소에는 수수료가 증가합니다. 수수료 메커니즘은 네트워크에 과부하가 걸리는 악의적인 트랜잭션을 줄이기 위해 설정됩니다.
State
내부 HRA 스토리지의 경우 다음 구조가 할당됩니다.
map [AnathaAddress]-> HRA []-Anatha 주소에서 주소 보유자가 소유한 HRA 목록으로의 매핑.
map [HRA]-> AnathaAddress-HRA의 해시된 값에서 소유자의 주소로 매핑
map [HRA]-> HraInfo-HRA의 해시된 값에서 주어진 HRA의 세부 사항을 설명하는 구조로 매핑
map [AnathaAddress] [CryptocurrencyId] [Index]-> Address-Anatha 주소를 여러 암호 화폐의 여러 주소에 매핑하는 매핑
각 HraInfo 구조는 다음 필드로 구성됩니다.
ExpiryTime-HRA의 만료 타임 스탬프
가격-UANATHA에서 HRA를 판매할 수 있는 가격입니다. 판매용이 아닌 경우 0
Messages
HRA 모듈은 다음 메시지 처리를 지원합니다.
RegisterHRA-서명자의 주소를 등록된 HRA에 연결하는 매개변수화된 비용이 있는 메시지입니다. 이 거래에 대한 추가 데이터로 사용자는 Anatha에 연결하려는 초기 암호화폐 지갑 주소를 전달할 수 있습니다. HRA를 처음 등록하는 경우 Anatha Wallet에서 생성된 주소는 소유자, 주소에 자동으로 연결됩니다.
RenewHRA-1 년 동안 HRA에 대한 소유권을 늘리고 매개변수화된 수수료가 부과되는 메시지
SetSellingPrice-주어진 HRA에 대한 가격을 설정하는 메시지
BuyHRA-HRA의 판매 가격과 일치하는 제공된 가격과 함께 메시지를 보내면 HRA가 구매자에게 전송됩니다.
DeleteHRA-AnathaAddress-> HRA 연관을 제거하는 메시지입니다. 이것이 사용자의 마지막 HRA 인 경우 모든 암호화폐 주소 매핑이 삭제됩니다.
TransferHRA-HRA를 다른 사용자에게 전송하는 메시지
RegisterAddress-사용자가 HRA를 통해 액세스할 수있는 Anatha 주소에 외부 암호화폐 주소를 연결할 수 있습니다.
DeregisterAddress-사용자가 이전에 등록된 외부 암호화폐 주소를 제거할 수 있습니다.
Keepers
HRA 모듈은 주소 변환이 필요한 다른 모듈에서 액세스할 수 있는 메인 키퍼를 노출합니다. 키퍼가 제공하는 대략적인 기능 목록은 다음과 같습니다.
GetHRAInfo-HRA 기본 정보를 반환합니다.
GetHRAByAddress-제공된 주소가 소유한 모든 HRA를 반환합니다.
GetAddressByHRA-Anatha 주소를 반환합니다.
PersistHRAInfo-수정된 HRA 관련 데이터 저장
Begin Block
만료된 HRA 정보 정리 및 매핑을 포함하는 모든 블록 유지 관리 절차가 시작될 때 실행됩니다.
Parameters
HRADenomination-기본 uANATHA
HRAAnnualPrice-이전 매개변수와 함께 연간 등록 총 가격이 계산됩니다. 기본값 100000000 = 1 ANATHA
TREASURY Module
Abstract
Treasury 모듈은 Anatha의 초기 공급을 담당하며, 자금에서 이전된 Anatha의 양을 기준으로 자금 공개 판매 가격을 생성하고 외부 Treasury System에 의해 다시 매입된 Anatha를 받습니다. Treasury 모듈은 제네시스 파일에 지정된 임계값 요구사항과 함께 온체인 다중서명 지갑에 의해 제어됩니다. 제품 문서의 목표를 달성하기 위해 이 온체인 모듈에는 백엔드 서비스 섹션에 설명된 보완 오프체인 모듈이 필요합니다.
Concepts
Treasury 모듈은 이 모듈의 방법을 호출할 수있는 Governance 모듈에 대한 경로를 노출합니다.Treasury 모듈에는 BuyBack queue 있으며 ANATHA 보유자는 ANATHA를 주문으로 보내고 교환 할 암호화폐를 지정합니다. Treasury Backend의 유동성이 허용되면 양도를 실행하고 ANATHA를 청구합니다.
State
Treasury 모듈은 Anatha 초기 공급의 유입 및 유출을 기반으로 요청가능한 현재 가격을 USD로 유지합니다. $ 0.01부터 시작하여 ANATHA 토큰 가격은 10,000,000 (1,000 만) 개의 ANATHA가 판매될 때마다 $ 0.01 씩 증가합니다.
0-10,000,000 토큰 판매 : $ 0.01
10,000,001-20,000,000 토큰 판매 : $ 0.02
20,000,001-30,000,000 토큰 판매 : $ 0.03
30,000,001-40,000,000 토큰 판매 : $ 0.04
...
7,690,000,001-7,700,000,000 토큰 판매 : $ 7.70
트레저리 실행을 기다리는 바이백 주문 큐를 보유합니다.
사용자 맵 [주소] 별 주문-> 주문 []
글로벌 주문 목록-> 주문 []
Keepers
트레저리 모듈 키퍼는 다음과 같은 기능을 제공합니다.
할인가 업데이트
할인가 노출
큐에서 주문 관리
Messages
TransferFunds-트레저리에서 지정된 주소로 자금을 이체하는 거버넌스 제안 기반
DepositFunds-매입 Anatha 반환 및 판매 가격 재조정
SellBack-예금은 ANATHA를 트레저리 펀드에 연결하고 메시지 메타데이터에는 ANATHA 보유자가 얻고자하는 암호화폐 식별자가 포함됩니다.
DeleteOrder-사용자가 주문을 제거할 수 있습니다.
FulfillOrder-SellBack 주문을 이행한 후 Treasury 백엔드에서만 보낼 수 있는 메시지입니다. 이것은 잠긴 자금을 트레저리 자금으로 돌려보낼 것입니다
ANATHA BACKEND SERVICES/ DASHBOARDS
GOVERNANCE Dashboard
거버넌스 모듈을 사용하면 블록체인이 온체인 거버넌스 시스템을 지원할 수 있습니다. 분산형 거버넌스 시스템으로 발전하기 전에 이 모듈은 임계값 온체인 다중서명 모델을 기반으로 거버넌스 절차를 구현합니다. 즉, 제네시스 블록에 등록된 참가자만 거버넌스 제안 및 투표를 생성할 수 있습니다. 업그레이드 모듈의 메커니즘을 활용하여 거버넌스 모듈을 분산 거버넌스로 자동 업데이트할 수 있습니다.
ADMINISTRATOR Dashboard
Anatha 관리자가 다양한 사설 네트워크 데이터에 액세스하고 네트워크 활동을 모니터링할 수 있는 웹 대시보드입니다. Anatha 관리자는 관리자 대시보드 내의 제어판에서 특정 시스템 전체 설정을 편집할 수도 있습니다.
TREASURY Dashboard
Treasury Backend는 Treasury 블록체인 모듈과 함께 작동하도록 설계되었으며 다음을 담당합니다.
트레저리 백엔드에서 관리하는 계정으로 이체된 ANATHA 관리
다양한 결제 방법을 처리하고 온체인 모듈에서 지정한 USD 판매 가격으로 구매자에게 ANATHA를 지급
고급 사용모드에서 시스템은 구매 주문을 더 저렴하게 이행할 수 있는 경우 시장을 스캔합니다. 가능하다면 이익은 Anatha에 의해 유지됩니다.
BLOCK Explorer
트랜잭션 및 전체 네트워크 데이터에 액세스하기 위한 API 연결 및 웹 인터페이스를 제공하는 표준 탐색기입니다. 탐색기는 네트워크 (블록, 트랜잭션, 주소, 잔액), HRA 레지스트리 (HRA 조회, HRAmapping) 및 유효성 검사기 (활성 번호, 성능)에 대한 일반 정보를 제공합니다.
VALIDATORS
자격을 갖춘 개인이 검증자로서 자신을 온보딩하고 Anatha 블록체인의 블록을 검증할 수 있는 프로그램입니다. 유효성 검사기 보안 및 일반 매개변수는 Anatha 네트워크에서 정한 표준을 기반으로 정의됩니다. 최소 검증자 요구사항에는 활성 HRA 소유, 스테이킹에 사용할 수 있는 500,000 ANATHA 소유, 99 % 이상의 서버 가동 시간이 포함됩니다.
제한:
시작할 수 있는 최대 노드 수-50
궁극적으로 최대 노드 수-300
대기 목록의 최대 노드 수-무제한
Anatha가 실행중인 총 노드 수-3
대기자 명단 리더 보드
INDEXER
인덱싱 서비스는 지갑 주소 및 트랜잭션 해시별로 트랜잭션을 인덱싱화함으로 특정 주소와 관련된 트랜잭션을 필터링하기가 더 쉽고 고유한 해시 (전체 트랜잭션 개체의 SHA256 해시)로 단일 트랜잭션을 쉽게 쿼리할 수 있습니다.
인덱싱 서비스는 기존 블록체인 노드의 새로운 트랜잭션을 지속적으로 구독하고 인덱싱된 데이터를 Redis 데이터 저장소에 저장합니다. 어떤 이유로 인덱싱 서비스가 작동을 중지하면 기존 데이터가 손실되지 않고 마지막으로 저장된 블록에서 동기화 프로세스를 계속합니다. 색인 생성 프로세스의 일부로 잘못된 트랜잭션도 저장되지만 잘못된 플래그로 플래그가 지정됩니다.
인덱싱 서비스는 블록체인에서 직접 쿼리할 수 없는 정보를 제공하는 쉽게 사용가능한 API를 제공합니다. 이러한 API는 블록체인 탐색기, 지갑 등과 같은 다양한 프런트엔드에서 사용됩니다.
인덱서가 인덱싱할 몇 가지 항목을 나열하려면 다음을 수행하십시오.
만료일별 HRA
주소별 거래
ANATHA JavaScript SDK
Anatha SDK는 npm 저장소에서 설치할 수 있는 JavaScript / Node.js 라이브러리입니다. 여기에는 Anatha 블록체인과 통신하는 방법이 포함됩니다. Anatha SDK는 개발자가 Anatha 블록체인과 상호 작용하고 인터페이스 및 애플리케이션을 구축하는 데 사용하기 위한 것입니다.
Anatha SDK는 모든 트랜잭션 유형을 가져오고 페이로드를 생성하고 Core에 지정된 모든 트랜잭션에 서명하기 위한 인터페이스를 제공합니다. 트랜잭션 제작, 서명 및 릴레이 외에도 Anatha SDK에는 블록체인 쿼리 기능이 있습니다. 기본 지갑 관련 기능도 지원합니다. 그런 의미에서 SDK는 CLI 도구와 동일한 19 가지 기능을 제공하지만 JavaScript 환경에 맞게 조정됩니다. SDK가 현재 제공하는 일부 기능 :
Anatha 지갑 (키페어) 초기화
키페어(keypair)을 생성하여
원시 개인키 가져오기
주소의 잔액 확인
Anatha 코인의 서명 및 거래
각 블록 및 각 트랜잭션에서 발생하는 WebSocket 이벤트 리스너
모듈 쿼리 및 트랜잭션 관련 기능 :
연결된 노드의 상태 조회
질문:
블록-주어진 높이에서 블록에 대한 검증된 데이터 가져오기
거래-주어진 태그 (이벤트) 또는 해시와 일치하는 모든 거래를 검색합니다.
계정 잔액
모든 모듈에 노출된 상태 (거버넌스, 배포, 스테이킹, 슬래싱, HRA, 저축, 트레저리, ...)
거래 :
서명된 트랜잭션 생성 및 릴레이
오프라인 생성 서명 브로드캐스트
모든 모듈에 노출되는 메시지 (거버넌스, 배포, 스테이킹, 슬래싱, HRA, 저축, 트레저리 등)
Command Line Tools
응용 프로그램의 주요 인터페이스 중 하나는 커멘드라인(command-line) 인터페이스입니다. 이 진입점은 최종 사용자가 메시지와 쿼리를 만들 수 있도록 애플리케이션 모듈의 명령을 추가합니다.
트랜잭션은 유효한 블록에 포함될 때 상태변경을 유발하는 메시지를 래핑하기 위해 사용자가 생성합니다. 트랜잭션 명령은 일반적으로 각 모듈 tx.go 파일에 표시됩니다.
쿼리를 통해 사용자는 애플리케이션 또는 네트워크 상태에 대한 정보를 수집할 수 있습니다. 응용 프로그램에 의해 라우팅되고 정의된 모듈에 의해 처리됩니다. 쿼리 명령에는 일반적으로 자체 query.go 파일이 있습니다.
CLI 도구는 anathacli라고 하며 컴파일된 Golang 바이너리 실행파일이 됩니다.
나열된 모듈의 각 메시지는 CLI로 작성할 수 있습니다.
Last updated
