용어집

A – B#

주소

20바이트 계정 식별자이며, 0x 뒤에 16진 40자를 붙여 씁니다. Arcscan은 대소문자가 섞인 EIP-55 체크섬 형태로 표시하고 링크하므로, 잘못 입력된 문자가 소리 없이 지나가지 않고 대개 눈에 띕니다. Arc의 주소는 ETH 잔액이 아니라 USDC 잔액을 보유합니다 — 네이티브 통화 항목을 보십시오.

아카이브 노드

과거 상태를 보관하는 노드로, “이 잔액은 200만 블록 전에 얼마였는가” 같은 질문에도 답할 수 있습니다. 두 Arc 체인은 이 점에서 다르며, 예상과는 반대입니다: /v1/chain은 메인넷에 archive: true, 테스트넷에 archive: false를 보고하므로 메인넷이 답하는 과거 상태 질문이 테스트넷에서는 거절될 수 있습니다.

기본 수수료

프로토콜이 블록마다 스스로 정하는 가스 단위당 가격이며, 이더리움과 똑같이 헤더의 baseFeePerGas에 담기고 Arcscan이 나열하는 모든 블록에 gwei로 표시됩니다. Arcscan은 블록의 소각 수수료를 총액과 따로 보고합니다: 소각 수치는 그 블록의 사용 가스에 기본 수수료를 곱한 값이고, 총액에서 남은 것은 제안자가 가져가는 우선 수수료입니다. 이 체인에서는 두 수치 모두 USDC 금액입니다.

블록 해시

블록 헤더의 32바이트 다이제스트이며 그 블록의 변하지 않는 신원입니다 — 부모 해시, 상태 루트와 영수증 루트, 타임스탬프, 그리고 헤더의 나머지에 대해 약속합니다. Arc는 일반적인 이더리움 블록 헤더를 쓰므로 해시는 다른 곳에서와 똑같이 보이고 똑같이 동작합니다. /v1/chain이 두 체인 모두 최종성을 instant로 보고하므로, 확률적 최종성을 가진 체인에서와 달리 하나의 높이가 실제로 경쟁하는 두 번째 해시를 갖는 일은 없습니다.

블록 높이

체인에서 블록의 위치이며, 첫 블록을 0으로 두고 셉니다. Arc는 대략 1초에 두 개꼴로 블록을 생성하고 — /v1/chain이 메인넷 506 ms, 테스트넷 536 ms의 블록 시간을 보고합니다 — 그래서 높이는 한 달에 수백만씩 올라갑니다. 높이는 데이터 범위와 같은 것이 아닙니다: Arcscan의 테스트넷 인덱스는 블록 53,500,000에서 시작하므로, 그보다 낮은 테스트넷 높이는 체인에는 존재하지만 이곳에는 보유되어 있지 않습니다.

C – F#

연속 구간

안쪽에 빠진 것 없이 이어진 높이의 묶음입니다. Arcscan은 각 인덱스 스트림을 구간들의 집합과 last_contiguous_block으로 기술하며, 그래서 어느 높이까지는 완전하고 그 위로는 구멍이 있다고 말할 수 있습니다. contiguous_from_genesis가 true인 단일 구간으로 보고된 스트림은 시작 블록 위로 구멍이 전혀 없습니다. 구간을 게시하는 이유는 빈 답에 이름을 붙일 수 있게 하기 위함입니다: 그것은 “아무 일도 없었음”이거나 “인덱싱되지 않음”이며, 둘은 다릅니다.

난이도

이더리움의 작업증명 시절에서 물려받은 헤더 항목입니다. Arc에서는 0x0이며 — 높이 1, 100,000, 10,000,000와 체인 헤드의 메인넷 헤더에서 직접 읽었습니다 — 따라서 블록이 어떻게 만들어졌는지에 대해 아무것도 말해 주지 않고 Arcscan도 이를 통계로 제시하지 않습니다. Arc에서 채굴되는 것은 없고, 보고할 해시레이트도 없습니다.

ERC-20 네이티브 USDC

Arc는 네이티브 USDC를 0x3600000000000000000000000000000000000000의 컨트랙트를 통해 노출하므로, 일반적인 ERC-20 도구로도 가스 자산을 옮길 수 있습니다. 두 형태는 소수 자릿수가 다릅니다: 네이티브 잔액은 18자리, 이 ERC-20 인터페이스는 6자리이며 둘 다 /v1/chain 기준입니다. 같은 금액에 두 가지 표기가 있다는 뜻이고, Arcscan은 언제나 어느 쪽을 보여 주는지 표시합니다. 이것에는 자신의 보유자 목록이 없습니다 — 요청하면 그 잔액이 곧 계정 잔액이며 다시 인덱싱하면 모든 계정을 이중으로 세게 된다는 거절이 돌아옵니다.

최종성

블록이 잠정 상태를 벗어나 더 이상 대체될 수 없게 되는 지점입니다. /v1/chain은 두 Arc 체인 모두에 instant를 보고하므로, Arcscan이 블록 안에 보여 주는 트랜잭션은 이미 확정된 것입니다: 기다려야 할 컨펌 수도, 표시해야 할 safe 대 finalized 구분도, 독자가 감안해야 할 재구성 위험도 없습니다.

G – I#

가스

트랜잭션이 소비하는 실행 작업의 단위이며, 수수료를 계산하는 근거입니다: 사용 가스에 실효 가스 가격을 곱합니다. Arc에서 그 수수료는 USDC로 표시되므로 그 안 어디에도 ETH는 없습니다. 각 헤더는 블록 전체의 가스 한도도 담습니다 — 이 페이지를 위해 표본으로 본 모든 메인넷 헤더에서 30,000,000였습니다 — 실제 사용된 가스와 나란히 놓입니다.

보유자

특정 토큰의 잔액이 0이 아닌 주소입니다. Arcscan은 두 체인 모두에서 보유자 인덱스를 유지하며(holder_index: true), 각 보유자의 공급량 비중을 잔액 및 그것이 유효했던 블록과 함께 보고합니다. 보유자 목록의 잔액은 상태에서 읽은 것이 아니라 전송 이력에서 파생된 것으로 표시되며, 네이티브 USDC 인터페이스는 제외됩니다 — ERC-20 네이티브 USDC 항목을 보십시오.

인덱스 스트림

Arcscan은 “체인”을 하나의 덩어리로 인덱싱하지 않습니다. 별도의 스트림을 돌리고 각각의 범위를 따로 게시합니다: chain(블록과 트랜잭션), balances, traces입니다. 이들은 서로 다른 높이에 있고, 그중 하나가 비어 있다고 해서 나머지가 불완전해지지는 않습니다 — 그래서 한 페이지가 블록에 대해서는 권위 있게 말하면서도 그 내부 전송에 대해서는 “인덱싱되지 않음”이라고 말할 수 있습니다.

내부 트랜잭션

외부 소유 계정이 서명해서가 아니라 트랜잭션 도중 컨트랙트가 만든 가치 이동이나 호출입니다. 내부 트랜잭션은 별도의 항목으로 온체인에 기록되지 않으며, 오직 트레이스의 일부로만 존재합니다. Arcscan은 트랜잭션 하나를 즉석에서 트레이스해 이를 보여 줄 수 있지만, 체인 전체나 주소별 목록에는 저장된 traces 스트림이 필요합니다. 그리고 메인넷에서 그 스트림은 현재 블록을 하나도 보유하지 않습니다 — 그래서 그런 질문에는 “없었다”로 읽힐 빈 목록 대신 “인덱싱되지 않음”으로 답합니다.

N – P#

네이티브 통화

가스를 지불하는 자산입니다. 두 Arc 체인 모두에서 그것은 /v1/chain 기준 소수 18자리의 USDC이며, ETH도 아니고 먼저 구해야 하는 별도의 가스 토큰도 아닙니다. Arcscan이 찍는 모든 수수료와 모든 네이티브 잔액은 USDC 금액이며, 다른 체인에서 Arc로 온 독자가 가장 흔하게 하는 잘못된 가정이 바로 이것입니다.

논스

계정의 경우, 이미 보낸 트랜잭션의 개수입니다: 보낸 쪽 트랜잭션의 순서를 고정하며 같은 값을 두 번 쓸 수 없습니다. 블록 헤더의 nonce는 이와 무관한 작업증명 잔재이고, 이 페이지를 위해 표본으로 본 모든 높이에서 전부 0이므로 어떤 것에 대한 통계도 아닙니다.

제안자

블록을 만들어 낸 것으로 기록되는 주소입니다. Arcscan 자체 API는 이를 proposer라고 부르지만, 그 값이 오는 JSON-RPC 헤더 항목의 이름은 여전히 miner입니다. Arc의 블록은 채굴되는 것이 아니라 제안되므로, 이것은 계산 경쟁의 승자가 아니라 블록이 귀속되는 검증자입니다. Arcscan은 그 주소와, 보유한 라벨이 있다면 그것도 함께 보여 줍니다.

프루닝

Arc의 노드는 헤드보다 뒤처진 블록 본문과 영수증을 버리면서 헤더는 남깁니다. 따라서 프루닝된 블록은 완전하고 검증 가능한 헤더 — 제안자, 사용 가스, 루트, 크기 — 를 갖지만 조회할 수 있는 트랜잭션 목록이나 수수료 총액은 갖지 않으며, Arcscan은 그 자리에 0이 아니라 알 수 없음을 찍습니다. 두 시계는 다릅니다: 영수증이 본문보다 먼저 사라지므로, 트랜잭션 목록은 나열할 수 있으면서도 수수료 총액은 조회할 수 없는 블록이 생길 수 있습니다.

R – V#

리버트된 트랜잭션

블록에 포함된 뒤 실행 중에 실패해 상태 변경이 되돌려진 트랜잭션입니다. 그래도 가스를 소비했고 수수료를 냈습니다 — 이 페이지를 위해 읽은 메인넷 사례는 아무 가치도 옮기지 않고 0.000869883 USDC를 냈습니다 — 그러므로 리버트된 트랜잭션은 성공한 것도 아니고 공짜도 아닙니다. Arcscan의 API는 그 상태를 failed로 보고하며, 어떤 Arcscan 화면도 이를 성공으로 그려서는 안 됩니다.

테스트넷

체인 5042002이며 이름은 Arc Testnet이고 testnet.arc-scan.io에서 따로 제공됩니다. 자신의 이력과 자신의 기능을 가진 별개의 체인이며, 두 가지 점에서 메인넷의 거울상입니다: 검증된 컨트랙트 소스를 보여 줄 수 있지만 과거 상태에 대한 질문에는 답할 수 없습니다. 또 Arcscan의 테스트넷 인덱스는 체인의 첫 블록이 아니라 블록 53,500,000에서 시작하므로 그 아래의 블록은 이곳에 전혀 보유되어 있지 않습니다.

트레이스

트랜잭션이 만든 호출의 트리를 프레임 단위로 기록한 것이며, 각 프레임은 trace_address 경로로 트리 안에서의 자기 위치를 나타냅니다. 내부 트랜잭션이 보이게 되는 것은 트레이스를 통해서입니다. Arcscan은 개별 메인넷 트랜잭션을 즉석에서 트레이스해 실제 프레임을 돌려줍니다. 메인넷에 없는 것은 저장된 트레이스 인덱스이며, 그래서 주소별·체인 전체의 내부 전송 질문은 부실하게 답하는 대신 거절합니다.

트랜잭션 해시

서명된 트랜잭션의 32바이트 다이제스트이며, 검색창에 붙여 넣는 식별자입니다. 트랜잭션이 서명되는 순간 — 어떤 노드가 포함하기도 전에 — 존재하므로, 완벽하게 유효한 해시가 Arcscan에는 아직 알려지지 않았을 수 있습니다. 즉시 최종성 덕분에 그 창은 짧지만 0은 아니며, Arcscan은 추측하는 대신 “찾을 수 없음”이라고 말합니다.

검증된 소스

공개된 Solidity가 실제로 배포된 바이트코드로 컴파일된다는 것이 증명된 컨트랙트입니다. Arcscan은 이를 Sourcify에서 가져오며, 두 체인은 대칭이 아닙니다. Arc 메인넷에서는 존재하지 않습니다 — 체인 5042에 대해 verified_source는 false입니다 — 그리고 API가 자신의 말로 이유를 밝힙니다:

Sourcify does not list chain 5042, so no contract on this chain can be verified today
— through Arcscan or through any other client of Sourcify. Nothing here is waiting on
Arcscan; it is waiting on the chain being added upstream.

테스트넷에서는 Sourcify에 그 체인이 등재되어 있어 소스를 보여 줄 수 있습니다 — 다만 Arcscan이 보유한 것은 특정 컨트랙트를 누군가 처음 요청할 때 채워지는 캐시이므로, Arcscan이 소스를 보유한 컨트랙트 수는 상위에서 검증된 컨트랙트 수보다 훨씬 적습니다.

숫자가 있는 곳#

이 페이지의 어떤 것도 의도적으로 개수가 아닙니다. Arcscan이 어떤 높이를 보유하고 있는지, 어떤 스트림이 뒤처져 있는지, 각 체인이 어떤 질문을 거절하는지는 모두 익스플로러 자신이 실시간으로 게시하며 데이터 범위에 정리되어 있습니다. 여기의 용어로도 의문이 남는다면 자주 묻는 질문이 사람들이 실제로 묻는 것에 답하고, 블록과 트랜잭션이 이 낱말들을 실제 페이지 위에서 보여 줍니다.