Arc 에서 금융 애플리케이션 구축: 다르게 작동하는 네 가지 사항

Quicknode

2026년 10월 8일 — 읽는 데 6분 소요

공유하기

선호하는 소스로 추가

Arc 실제 가치를 이동시키는 애플리케이션을 위해 설계되었습니다. 이 플랫폼은 EVM 실행 환경을 유지하므로, 기존의 솔리디티(Solidity) 계약과 익숙한 이더리움 개발 도구( Ethereum )를 계속 활용할 수 있는 동시에, 수수료, 결제 및 기타 금융 관련 요건을 네트워크 자체로 통합합니다.

이러한 선택 사항은 계약과 관련된 시스템을 변경합니다. 아래에 제시된 네 가지 차이점 중 두 가지는 오늘 Arc 에서 적용 중이며, 나머지 두 가지는 로드맵에 포함된 항목으로, 현재 구현된 기능이 아닌 향후 방향성으로 이해해야 합니다.

1. 가스 비용으로 사용되는 USDC

스테이블코인 애플리케이션은 한 가지 작업을 완료하기 위해 종종 두 가지 자산이 필요합니다. 바로 이동되는 스테이블코인과 실행 비용을 지불하기 위한 별도의 토큰입니다. 이로 인해 자금을 조달해야 할 또 다른 잔고가 생기고, 가격을 책정해야 할 또 다른 자산이 생기며, 사용자가 자금은 있지만 가스가 부족할 때 발생하는 또 다른 오류 mode 가 발생합니다.

Arc USDC를 네이티브 가스 자산으로 채택함으로써 이러한 분리를 해소합니다. 거래 수수료와 애플리케이션 가치는 동일한 회계 단위를 공유하므로, 사용자는 별도의 가스 토큰을 취득하지 않고도 거래를 진행할 수 있습니다. 또한 재무 및 회계 시스템은 별도의 환산 단계를 거치지 않고도 이체 내역과 실행 비용을 달러 단위로 기록할 수 있습니다. Arc 의 수수료 설계는 네트워크 수요 변동을 완화하여 비용 추정을 용이하게 하며, 표준 수수료 RPC 메서드를 통해 애플리케이션은 실행 시점에 현재 값을 읽을 수 있습니다.

통합 과정에서 특별히 고려해야 할 세부 사항이 하나 있습니다. 네이티브 USDC는 가스 및 EVM 가치 전송 시 소수점 이하 18자리를 사용하는 반면, ERC-20 인터페이스는 익숙한 소수점 이하 6자리 USDC 표기법을 사용합니다. 이는 서로 다른 두 자산이 아니라 동일한 잔액을 나타내는 두 가지 관점일 뿐입니다. 따라서 지갑과 원장 시스템은 두 가지 관점을 모두 표시하거나 합산하기보다는 이를 표준화해야 합니다. 인덱서 역시 동일한 원칙을 준수해야 합니다. ERC-20 거래는 단일 이동에 대해 네이티브 시스템 이벤트와 인터페이스 이벤트를 모두 생성할 수 있는 반면, 네이티브 전송은 시스템 이벤트만 생성하기 때문입니다. Arc 에 게시된 USDC 인덱싱 가이드의 mainnet 예시에서는 실제 두 건의 USDC 이동에 대해 네 개의 전송 형태의 로그가 표시됩니다. 핵심은 다음과 같습니다. Arc 는 별도의 가스 자산을 제거할 뿐, USDC에 대한 단일 표준 뷰의 필요성을 없애지는 않습니다.

2. 결정론적 최종성

많은 네트워크에서 블록에 거래가 포함되었다고 해서 애플리케이션이 해당 거래를 안전하게 확정된 것으로 간주할 수 있는 것은 아닙니다. 서비스들은 더 많은 확인을 기다리고, 최근 활동을 잠정적인 상태로 유지하며, 체인이 재구성될 경우에 대비해 롤백 경로를 확보해 둡니다.

Arc's Malachite BFT 합의 알고리즘은 이러한 중간 상태를 제거합니다. 트랜잭션은 미확인 상태이거나 최종 확정된 상태 중 하나이며, 커밋된 블록은 재구성될 수 없습니다. 애플리케이션은 확인 깊이를 신뢰도 점수로 변환하는 대신, 블록이 커밋될 때 조치를 취할 수 있습니다.

이를 통해 온체인 결과가 나온 후 다른 곳에서 시작되는 워크플로우(장부 업데이트, 재고 해제, 다른 서비스에 알림 전송, 다음 거래 시작 등)가 간소화됩니다. 확인 임계값 및 재구성 롤백 로직은 애플리케이션 상태 머신을 벗어날 수 있습니다. ‘ Arc ’에서는 1초 이내의 불가역적 결제를 측정된 운영 서비스 수준 계약(SLA)이 아닌 네트워크 설계 속성으로 다루고 있으므로, 팀은 여전히 사용자가 경험하는 전체 경로를 측정해야 합니다.

최종성은 운영상의 안정성을 대체하지 않습니다. 연결이 끊어지기도 하고, 클라이언트가 재시작되기도 하며, 전송이 재시도되기도 하고, 데이터베이스에서 타임아웃이 발생하기도 합니다. 내구성 있는 데이터 수집, 항등적 쓰기, 재실행 안전성, 그리고 조정 기능은 여전히 필수적입니다. ` Arc `는 체인의 응답을 최종적인 것으로 만듭니다. 애플리케이션은 여전히 해당 응답을 안정적으로 처리해야 합니다.

3. 별도의 실행 모델로서의 프라이버시

금융 애플리케이션은 종종 거래를 별개의 시스템으로 옮기지 않으면서도 기밀성을 유지해야 할 필요가 있습니다. 거래 조건, 잔액, 포지션 또는 거래 상대방에 대해서는 공개를 통제해야 할 수 있지만, 그로 인해 발생하는 가치 변동은 여전히 공개된 온체인 활동과 조화를 이루어야 합니다.

Arc 프라이버시 부문 (APS)은 ‘ Arc ’가 계획 중인 대응 방안입니다. 이는 로드맵에 포함되어 있으나 아직 출시되지 않았으므로, 현재 제품에 대한 약속이라기보다는 향후 아키텍처의 방향성을 제시하는 것으로 보아야 합니다.

APS는 공개 EVM과 병행하여 솔리디티 계약을 실행하기 위한 기밀 실행 환경으로 설계되었습니다. 공개 상태와 비공개 상태가 동일한 블록에 기록되므로, 두 환경의 계약이 원자적으로 상호작용할 수 있습니다. 이를 통해 별도의 브리지나 지연 메시징 계층에 의존하지 않고도, 민감한 상태는 비공개로 유지하면서 관련 공개 효과를 처리하는 워크플로우를 구현할 수 있습니다.

개인정보 보호의 경계가 명확해집니다. 함수, 저장소, 이벤트는 기본적으로 숨겨져 있으며, 애플리케이션이 무엇을 노출할지, 어떤 계약 간에 상호작용할 수 있을지 결정합니다. 이를 통해 기밀성은 이미 생성된 공개 데이터를 은폐하려는 별도의 계층이 아닌, 실행 설계의 일부가 됩니다. APS는 현재 사용할 수 없지만, 이 기술이 목표로 하는 장점은 분명합니다. 바로 솔리디티(Solidity)나 원자적 조합을 포기하지 않으면서도 개인정보를 보호할 수 있다는 점입니다.

4. 양자 컴퓨팅 시대 이후의 지갑 서명

오늘날 지갑을 보호하는 서명 방식은 충분히 성능이 뛰어난 양자 컴퓨터 앞에서는 더 이상 안전하지 않을 수도 있습니다. 장기적인 가치를 지닌 애플리케이션의 경우, 이러한 가능성에 대비하는 것은 막판에 서둘러 진행하는 소프트웨어 업데이트가 아니라 마이그레이션 문제입니다.

Arc의 양자 컴퓨팅 대비 로드맵은 mainnet 에서 SLH-DSA-SHA2-128s 지갑 서명에 대한 베타 단계의 선택적 지원으로 시작됩니다. 이 기능을 선택한 지갑은 새로운 방식을 사용하여 거래를 승인할 수 있습니다. 이러한 보호 기능은 지갑에만 적용되며, 검증자 서명에는 적용되지 않으며, Arc 의 합의 알고리즘을 양자 컴퓨팅에 대비하도록 만들지도 않습니다.

프로토콜 지원은 단지 첫 단계에 불과합니다. 하드웨어 지갑, 서명 서비스, SDK, 보관 정책, 복구 시스템, 거래 도구 등은 모두 해당 체계를 올바르게 처리해야 합니다. 표준은 여전히 발전 중이므로, ‘ Arc ’는 즉각적인 전환보다는 점진적인 과정을 통해 도입이 이루어질 것으로 예상합니다.

이 로드맵은 보호 기능을 단계적으로 확대합니다. 지갑 관련 작업에 이어 비공개 실행을 위한 양자 저항 암호화 및 오프체인 인프라 업그레이드가 진행될 예정이며, 검증자 서명은 여전히 장기적인 과제로 남아 있습니다. 따라서 이번 베타 버전의 실질적인 가치는 명확합니다. 즉, 참여 지갑들이 네트워크의 나머지 부분에서 제공되는 보호 수준을 과대평가하지 않으면서도 양자 저항 인증 체계를 조기에 테스트하고 도입할 수 있는 길을 열어줍니다.

네트워크 설계부터 애플리케이션 동작까지

이러한 차이점들은 하나의 목적을 공유합니다. 이더리움 2.0( Arc )은 반복적인 금융 요구 사항을 네트워크에 더 가깝게 가져오고 있습니다. 즉, 가치와 수수료를 측정하는 안정적인 단위, 명확한 정산 경계, 기밀성을 보장하는 실행 경로, 그리고 지갑 인증 방식을 발전시킬 수 있는 방법을 제공합니다. EVM 호환성을 통해 개발자들은 이미 익숙한 계약과 도구를 포기하지 않고도 이러한 기반을 활용할 수 있습니다.

애플리케이션에는 여전히 정확한 회계 처리, 신뢰할 수 있는 데이터 파이프라인, 신중한 접근 제어, 그리고 안전한 지갑 인프라가 필요합니다. ‘ Arc ’는 이러한 시스템의 기반을 변화시켜, 익숙한 복잡성 중 일부를 제거하는 동시에 정확히 이해해야 할 새로운 한계들을 도입합니다.

Quicknode 지원 Arc JSON-RPC 및 WSS 엔드포인트를 통해 디버그 및 추적 네임스페이스를 포함한 전체 아카이브 액세스, WebSocket 구독, Webhooks, 그리고 Streams. 지금 바로 Arc 에서 개발을 시작하세요 Quicknode 개발을 시작해 보세요.