트랜잭션
트랜잭션 페이지는 세 가지 질문에 답합니다 — 무언가 하긴 했는가, 무엇을 옮겼는가, 비용은 얼마였는가 — 그리고 Arc에서는 그 셋 모두, 대부분의 익스플로러 독자가 익숙한 체인들과 다른 답을 갖습니다.
트랜잭션 페이지가 담는 것#
트랜잭션 목록에서, 블록에서, 또는 해시를 검색창에 붙여 넣어 트랜잭션을 여십시오. 개요는 라벨이 붙은 행이 이어지는 하나의 흐름입니다 — 트랜잭션 해시, 상태, 블록, 타임스탬프, 보낸 주소, 상호작용 대상(받는 주소), 그다음 금액과 토큰 이동, 그리고 금액, 트랜잭션 수수료, 가스 가격. 그보다 무거운 것은 모두 각자의 탭에 놓이므로 트랜잭션을 여는 일이 트레이서를 기다리는 법은 없습니다.
| 탭 | 보여 주는 것 |
|---|---|
| 개요 | 위의 라벨 행들과, 가스 한도 및 사용량, 수수료 분해, 기타 속성, 디코딩된 입력 데이터를 담은 추가 상세 접힘 영역. |
| 내부 트랜잭션 | 해당 블록에 대해 트레이서가 아직 콜 트리를 만들어 낼 수 있는 경우의 콜 트리입니다. 아래를 보십시오 — 여기서 빈 표는 거짓 진술이 되므로 페이지는 그것을 그리지 않습니다. |
| 로그 | 이 트랜잭션이 발행한 모든 이벤트이며, 이벤트 시그니처를 아는 경우 디코딩됩니다. 탭 라벨의 숫자는 로그 개수입니다. |
| 상태 | 이 트랜잭션이 일으킨 잔액·논스·스토리지의 차이이며, diff 모드 트레이서에서 나옵니다. |
| 원본 트랜잭션 JSON 보기 | 노드 자신이 내놓은 트랜잭션과 영수증의 JSON을 그대로 복사할 수 있게 보여 줍니다. 탭이 아니라 그 옆 ⋮ 메뉴 안에 있습니다. |
상태#
상태 값은 둘이 아니라 셋입니다. 영수증에서 읽는 값이며, 영수증은 실행이 완료되었다고 말하거나, 리버트되었다고 말하거나, 더 이상 읽을 수 없거나 셋 중 하나입니다.
| 배지 | 뜻 |
|---|---|
| 성공 | 영수증이 실행이 완료되었다고 말합니다. |
| 실패 | 트랜잭션이 리버트되었습니다. 시도한 것 중 반영된 것은 없지만 트랜잭션은 체인 위에 있고 수수료는 그대로 청구되었습니다. |
| 알 수 없음 | Arcscan은 둘 중 어느 쪽이 일어났는지 알려 드릴 수 없습니다. 트랜잭션 자체는 확정되어 있고 변하지 않습니다. |
리버트된 트랜잭션을 성공으로 표시하는 일은 결코 없습니다
이것은 사연이 있는 규칙입니다: 이전 빌드가 영수증이 없을 때 기본값을 성공으로 두어, 리버트된 트랜잭션에 초록색 체크를 달아 내보낸 적이 있습니다. 리버트 사유를 복원할 수 있는 경우에는 그것을 디코딩해 배지 옆에 보여 줍니다 — 컨트랙트 자신의 require 메시지, 컴파일러 패닉 코드, 또는 인자가 붙은 이름 있는 커스텀 오류 — 그리고 원본 리버트 페이로드는 한 번의 클릭 거리에 남겨 둡니다. 그 줄의 나머지 모든 것은 그것에 대한 해석이기 때문입니다.
결과를 알 수 없을 때#
트랜잭션의 결과는 오직 영수증에만 존재합니다. 노드는 블록 본문은 훨씬 오래 보관하면서 영수증은 이동 창 방식으로 프루닝하므로, 그 경계를 넘어서면 트랜잭션은 여전히 표시되지만 결과는 노드에서 복원할 수 없습니다. Arcscan 자체 인덱스가 그 간극의 대부분을 메우므로, ‘알 수 없음’은 두 출처 모두 영수증을 갖고 있지 않은 경우에만 여러분에게 닿습니다. 그것은 오류도 로딩 상태도 아닌 진짜 답이며, 페이지는 회색 알약 옆에 0원짜리 수수료를 찍는 대신 문장으로 그렇다고 밝힙니다. 범위가 어디에서 시작하고 끝나는지는 데이터 범위에 더 있습니다.
대기 상태도, 컨펌도 없습니다#
Arc는 최종성을 instant로 보고합니다: 블록은 커밋되는 순간 확정되고 재구성으로 사라지지 않습니다. 그래서 트랜잭션 페이지 어디에도 컨펌 카운터가 없고 — 안전을 향해 올라가는 숫자란 것이 없습니다 — 대신 Arcscan은 블록 옆에 확정된 상태를 보여 줍니다. 마찬가지로 보내 드릴 대기 화면이나 멤풀 화면도 없습니다. 보여 줄 대기 상태가 존재하지 않기 때문입니다.
그렇다면 아무것도 나오지 않는 해시는 무슨 뜻인가?
두 가지이며, 페이지는 추측하는 대신 둘 다 밝힙니다. 트랜잭션이 Arcscan이 읽어 들인 데이터보다 새롭거나, 아니면 노드가 충분히 오래된 블록에 대해 해시→블록 조회 표를 프루닝한 것입니다 — 후자라면 블록은 여전히 그 트랜잭션을 나열하고 해시로 찾는 길만 사라진 것입니다. 어느 쪽인지 판단하실 수 있도록 헤드 블록 높이를 함께 찍습니다.
가스와 수수료는 USDC입니다#
Arc의 네이티브 자산 — 가스를 지불하는 대상 — 은 소수 18자리의 USDC입니다. 이 사실 하나가 다른 체인의 수수료에 필요한 환산을 없앱니다: 수수료와 그 달러 가치가 같은 숫자이므로, 페이지의 어떤 것도 환율을 곱한 값이 아닙니다.
| 행 | 무엇인가 |
|---|---|
| 금액 | 이 트랜잭션 자체가 옮긴 USDC이며 소수 18자리입니다. |
| 트랜잭션 수수료 | 이를 처리하기 위해 지불된 총액이며 단위는 USDC입니다. |
| 가스 가격 | 가스 한 단위당 실효 가격을 Gwei로 전체 정밀도로 표시하고, 같은 가격을 네이티브 금액으로 옆에 다시 적습니다. 가격 × 사용 가스가 수수료와 맞아떨어져야 하므로 반올림하지 않고 찍습니다. |
| 가스 한도 및 트랜잭션 사용량 | 설정된 한도, 실제로 사용된 가스, 그리고 그 비율입니다. |
| 소각 및 검증자 팁 | 위 트랜잭션 수수료를 분해한 것이며 추가 청구가 아닙니다: 기본 수수료 부분은 소각되고, 우선 수수료 부분은 제안자에게 지급되며, 둘의 합이 수수료입니다. |
두 개의 소수 배율, 하나의 달러#
같은 달러가 온체인에서 두 얼굴을 가지며, 이 둘을 12자리만큼 헷갈리는 것이 이 체인에서 가장 흔한 혼동입니다. 네이티브 USDC — 금액, 가스, 수수료 — 는 소수 18자리입니다. USDC의 ERC-20 컨트랙트는 0x3600000000000000000000000000000000000000에 있고 소수 6자리입니다. 금액은 언제나 해당 자산에 대해 페이로드가 선언한 소수 자릿수로 표시되며, 18자리라고 가정하는 일은 결코 없습니다. ⋮ 메뉴의 단위 변환기가 바로 이럴 때 쓰라고 있습니다. 토큰 이동은 토큰에서 다룹니다.
로그#
로그 탭은 영수증을 두 번 읽습니다. 먼저 문장으로 — 어떤 로그가 가치를 옮겼는지, 누구에게서 누구에게로 — 대부분의 독자가 들고 온 질문이 그것이기 때문입니다. 그다음에는 이벤트 자체로: 발행한 컨트랙트, 디코딩된 이벤트 이름과 시그니처, 이름 붙은 파라미터로 풀어낸 인덱스 토픽, 이름 붙은 항목으로 정리한 데이터 영역, 그리고 원본 토픽과 워드는 언제나 버튼 하나 거리에 있습니다.
디코딩은 최선을 다하되 결코 추측하지 않습니다. 시그니처를 알 수 없는 이벤트는 지어낸 이름이 아니라 번호가 매겨진 토픽과 번호가 매겨진 데이터 워드로 표시됩니다. 두 화면은 하나의 영수증에서 나오므로 서로 일치해야 합니다. 일치하지 않으면, 페이지는 긴 목록 위에 짧은 요약을 얹어 넘겨짚게 만드는 대신 경고를 찍습니다.
내부 트랜잭션#
내부 트랜잭션은 하나의 트랜잭션이 자기 안에서 만든 호출들이며, 여기에는 혼동하기 쉬운 서로 다른 두 가지가 있습니다. 하나의 트랜잭션에 대한 콜 트리는 탭을 열 때 트레이서가 즉석에서 만들어 내며, 오늘 메인넷에서 동작합니다. 체인 전체를 대상으로 검색할 수 있는 내부 트랜잭션 인덱스는 별개의 것으로, traces 스트림에서 만들어집니다 — 그리고 그 스트림은 현재 두 체인 모두에서 블록을 하나도 보유하지 않습니다.
오늘 트레이스 인덱스는 두 체인 모두 비어 있습니다
2026년 8월 10일 측정: traces 스트림은 메인넷과 테스트넷 모두에서 인덱싱된 블록 0개, 구간 없음을 보고합니다. 따라서 체인 전체의 내부 트랜잭션 목록은 지금 인덱스에서 답할 수 없고, 주소 페이지도 인덱스에서 내부 전송을 나열할 수 없습니다. 이것은 Arcscan이 인덱싱한 범위의 공백이지, 그 호출들이 일어나지 않았다는 주장이 아닙니다.
콜 트리를 만들어 낼 수 없는 경우 페이지는 빈 표를 그리는 대신 그렇다고 말합니다. 빈 표는 “이 트랜잭션은 내부 호출을 하지 않았다”로 읽히는데, 그것은 체인에 대한 거짓 진술이기 때문입니다. 산수가 이 구분을 확실하게 만들어 줍니다: 실행된 모든 트랜잭션은 최상위 호출이라는 프레임을 최소 하나 가지므로, 프레임 0개는 트레이스가 만들어지지 않았다는 뜻일 수밖에 없습니다. 진짜로 비어 있는 경우는 프레임이 하나뿐일 때입니다. 트레이서가 답하지 못하면 Arcscan은 영수증이 여전히 증명하는 것으로 물러섭니다: Arc에서는 네이티브 순이동도 로그로 발행되므로, 프레임을 복원할 수 없어도 트랜잭션 안에서 옮겨진 금액은 복원할 수 있습니다.
영수증을 직접 가져오기#
rpc.arc-scan.io새 탭에서 열립니다는 Arc 메인넷, 체인 5042(0x13b2)를 위한 공용 읽기 전용 JSON-RPC 엔드포인트입니다. 여러 독립적인 제공자 앞에서 페일오버와 함께 동작하며 일반적인 읽기 메서드에 답하므로, 트랜잭션 페이지의 어떤 수치든 체인에서 직접 대조해 보실 수 있습니다.
curl -s https://rpc.arc-scan.io \ -H 'content-type: application/json' \ -d '{"jsonrpc":"2.0","id":1, "method":"eth_getTransactionReceipt", "params":["0xYOUR_TX_HASH"]}'
영수증의 status는 완료된 트랜잭션이면 0x1, 리버트된 것이면 0x0이며, 상태 배지가 그려 내는 것과 같은 사실입니다. 그 호스트명에 테스트넷 엔드포인트는 없습니다. 메서드 목록과 한도는 공용 RPC를, Arcscan 자체 엔드포인트가 반환하는 형태는 REST API를 보십시오. 트랜잭션이 담기는 그릇은 블록에서 다룹니다.