DSRV에서 AWS 서비스를 활용한 안정적인 밸리데이터 노드 운영 사례

흔히 잘 알려진 이더리움, 솔라나 등의 블록체인은 대부분 독립적인 네트워크로 존재하며 다른 블록체인과의 통신 기능이 없습니다. 이에 따라 파편화된 블록체인 생태계에서 상호운용성(interoperability)에 대한 필요성이 대두되며, 단순한 토큰 전송을 넘어 체인간 메시지 전달까지 지원하는 프로토콜이 등장하였습니다. 이러한 배경에서 주목 받고 있는 하이퍼레인은 독립적인 네트워크를 가진 다양한 체인간의 통신을 가능하게 해주는 비허가형(permissionless) 상호운용성 프로토콜입니다. 하이퍼레인은 한 체인에서 다른 체인의 데이터를 읽고 쓸 수 있게 하여, 블록체인 개발자가 다양한 체인을 넘나드는 탈중앙화 어플리케이션 (Decentralized application 또는 DApp)을 쉽게 개발할 수 있게합니다.

이번 글에서는 하이퍼레인의 동작 원리와 검증자의 역할을 살펴보고 DSRV가 AWS 환경에서 하이퍼레인 검증자를 안정적으로 구축하고 운영하는 방식에 대해 설명합니다.

DSRV 소개

DSRV는 지속 가능한 웹3 생태계를 위한 인프라를 제공하고 필요한 솔루션을 개발하는 기업입니다. 50개 이상 글로벌 블록체인 프로토콜의 검증자(Validator)이자, 엔터프라이즈급 NaaS (Node-as-a-Service) 및 멀티체인 환경에 최적화된 개발 도구를 제공하는 인프라 제공자로서 더 나은 블록체인 개발 환경을 선도하고 있습니다. DSRV는 이러한 노력의 일환으로, 하이퍼레인에 검증자로 참여하고 있습니다.

하이퍼레인 동작 방식

하이퍼레인은 Mailbox 스마트 컨트랙트, Interchain Security Module(ISM) 스마트 컨트랙트, 검증자, 그리고 릴레이어(Relayer)로 구성되어 있습니다. 스마트 컨트랙트(Smart Contract)는 블록체인 위에서 특정 조건이 충족될 때 실행되는 프로그램의 일종입니다. 아래 다이어그램에서 실선은 직접적인 상호작용, 점선은 간접적인 상호작용 및 의존성을 나타냅니다. 예시를 통해 각 구성요소들이 어떻게 상호작용 하는지를 살펴보겠습니다.

스마트 컨트랙트 개발자가 한 체인의 컨트랙트에서 다른 체인의 컨트랙트를 호출하려 한다고 가정해 보겠습니다. 개발자는 발신 체인(origin chain)에서 Mailbox를 호출하여 발신 컨트랙트 주소, 수신 체인(destination chain), 수신 컨트랙트 주소, 메시지 내용을 기록한 트랜잭션을 전송합니다. Mailbox는 통신을 위한 사용자 인터페이스로 하이퍼레인이 지원하는 모든 체인에 배포되어 있습니다. 하이퍼레인 팀이 공식적으로 지원하는 체인 뿐만 아니라 사용자가 직접 Mailbox를 배포하여 원하는 체인과의 통신을 시작할 수도 있습니다.

하이퍼레인 밸리데이터 동작 방식

하이퍼레인 밸리데이터 동작 방식 (참고: Validators | Hyperlane v3 Docs)

메시지는 릴레이어를 통해 수신 체인으로 전달됩니다. 릴레이어는 다양한 체인에 배포된 Mailbox를 감시하다가 새 메시지가 접수되면 이를 수신 체인에 전달하는 역할을 합니다. 그리고 수신 체인에는 전달된 메시지가 실제로 발신 체인에서 전송되었으며 위변조되지 않았는지를 확인하는 ISM 컨트랙트가 존재합니다. 개발자는 ISM 인터페이스를 통해 자신이 원하는 보안 모델에 따라 커스텀 ISM 컨트랙트를 구현할 수 있습니다. 릴레이어가 메시지와 함께 ISM에 필요한 메타데이터를 수집하여 수신 체인에 트랜잭션을 전송하면, 수신 체인의 Mailbox는 ISM을 통해 메시지의 유효성을 확인한 후 이를 수신 컨트랙트에 메시지를 전달하여 실행합니다.

검증자는 이 과정에서 메시지를 검증하고 이를 ISM에 필요한 데이터로 제공합니다. 검증자는 Mailbox를 감시하다, 트랜잭션이 발생하면 해당 트랜잭션이 체인에서 확정되었음을 확인하고 발신 체인 Mailbox의 최신 상태를 나타내는 머클 루트(Merkle root)에 서명하여 공개된 저장소에 저장합니다. 릴레이어는 이 서명을 수집하여 메시지 전송의 보안과 안전성을 높입니다.

DSRV는 AWS 환경에서 안전하게 하이퍼레인의 검증자 역할을 수행하고 있습니다. 이제 AWS 환경에서 구축시 사용한 서비스에 대해 간략하게 살펴보겠습니다.

하이퍼레인 검증자 노드를 AWS 환경에서 구축 시 사용한 서비스

검증자 노드를 운영하기 위해서는 RPC 노드, 안전한 서명 키, 그리고 공개된 읽기 전용 스토리지가 필요합니다. DSRV는 효율성과 보안성, 그리고 구축효율성 높이기 위해 AWS IAM, AWS KMS, Amazon S3 서비스 등을 활용했습니다.

하이퍼레인은 여러 블록체인 네트워크를 지원하므로, 각 네트워크마다 별도의 검증자 노드가 필요합니다. 따라서 검증자 노드는 네트워크별로 개별 IAM 사용자와 정책, KMS 키, S3 버킷과 EC2 인스턴스를 갖추고 있습니다.

서비스구성

1. AWS IAM

AWS IAM를 통해 하이퍼레인 검증자 노드마다 세분화된 IAM 사용자(User)와 정책을 두어 접근을 제한하고 각 검증자 노드가 필요로 하는 최소한의 권한만을 부여해 보안을 강화합니다.

2. AWS KMS

AWS KMS를 이용해 하이퍼레인이 지원하는 체인의 키를 안전하게 생성, 암호화, 저장 및 관리하며 이를 이용해 checkpoint에 서명합니다. (checkpoint는 특정 시점의 Mailbox의 머클 루트를 의미합니다.)

3. Amazon EC2 (Hyperlane Validator)

하이퍼레인이 지원하는 각 체인 별로 EC2 인스턴스를 구축하고 검증자 노드를 호스팅합니다. EC2 인스턴스에 구축한 검증자 노드는 RPC 노드를 통해 체인의 상태를 읽고, IAM 사용자를 통해 KMS 키로 서명한 후, S3 버킷에 checkpoint 서명을 기록합니다.

4. Amazon S3

Amazon S3에 각 검증자 노드별로 버킷을 구성하고 IAM 정책을 통해 검증자 노드만 서명을 저장할 수 있게 합니다.
버킷 정책(Bucket Policy)을 통해 공개 읽기 접근만 가능하도록 설정하여 릴레이어가 서명을 읽을 수 있게 합니다.

AWS에서 검증자 노드 실제 구성해보기

지금부터 단계별 상세 구성 가이드를 통해서 AWS 서비스를 활용한 검증자 노드 구축 과정을 살펴보겠습니다.

1. IAM 사용자 생성

하이퍼레인이 지원하는 각 블록체인별로 IAM 사용자를 생성합니다. 그리고 사용자는 security credential로 액세스 키를 발급 받습니다. 사용자는 이 액세스 키로 각 체인의 KMS 키로 서명할 수 있으며 S3 버킷에 접근할수 있습니다.

AWS console 에서 IAM 서비스로 이동합니다.
hyperlane-validator-${chain_name} or hyperlane-relayer-${chain_name} 로 새로운 사용자를 생성합니다. (사용자 생성시 어떤 권한설정도 필요 없습니다.)
새로 생성된 사용자에게 새로운 액세스 키를 발급합니다.

2. KMS 키 생성

각 체인별 검증자 노드는 KMS 서비스에서 서명에 필요한 키를 생성하고 등록합니다. 이후 이 KMS 키를 사용하여 checkpoint에 서명합니다.

AWS 콘솔에서 Key Management Service (KMS)로 이동합니다.
KMS 키를 저장할 region을 선택한 후, Customer-managed keys 옵션 선택후 아래의 필요한 사용예제를 지정합니다.
- Key type: Asymmetric
- Key usage: Sign and verify
- Key spec: ECC_SECG_P256K1
각 설정을 저장한 후, 새로운 키의 Alias를 아래와 같이 지정합니다.
- hyperlane-validator-signer-${chain_name} 또는 hyperlane-relayer-signer-${chain_name}
KMS 키 관리자를 설정하고, 이때 필요한 사용권한을 위에서 생성했던 IAM 사용자에게 부여합니다.
Key policy 섹션으로 이동하여 다음을 수정후 키 생성을 완료합니다.
- “Sid”가 “Allow use of the key”인 항목의 Action에서 KMS “kms:GetPublicKey”, “kms:Sign”등을 제외한 모든 관련작업을 제거합니다.
- “Sid”가 “Allow attachment of persistent resources”인 전체 문장을 제거합니다.

3. 주소확인 (Query address)

각 검증자는 이전 설정에서 구성했던 액세스 키와 KMS 키로 생성한 체인 주소가 필요합니다. 릴레이어는 검증자의 서명을 식별하기 위해 해당 검증자의 체인 주소를 사용합니다. 따라서 검증자는 자신의 체인 주소를 해당 체인의 특정 컨트랙트에 기록하는 트랜잭션을 전송하여 릴레이어가 이를 인식할 수 있도록 해야 합니다. 이러한 과정을 자동화하기 위해, 검증자는 체인 주소를 이후 검증자 노드의 설정 파일에 기입해야 합니다.

1. 이전 설정을 기반으로 액세스 키 및 KMS 키 변수를 설정합니다.

AWS_ACCESS_KEY_ID=${ACCESS_KEY_ID}

AWS_SECRET_ACCESS_KEY=${SECRET_ACCESS_KEY_ID}

AWS_KMS_KEY_ID=${KEY_ID}

2. 다음 저장소에 있는 스크립트를 사용하면 이 주소를 조회할 수 있습니다.

https://github.com/tkporter/get-aws-kms-address

4. S3 버킷 생성 및 권한 구성

각 검증자 노드별로 S3 버킷을 만듭니다. 검증자의 IAM 사용자는 서명을 저장하기 위해서 쓰기 권한이 필요하며 릴레이어는 이를 공개적으로 읽을 수 있어야 합니다.

4.1. S3 버킷 생성

AWS 콘솔에서 S3로 이동해 새로운 버킷을 만듭니다.
버킷 이름은 hyperlane-validator-signatures-${validator_name}-${chain_name} 같이 설정합니다.
KMS 키와 동일한 리전을 선택하고 “ACLs disabled” 설정을 유지합니다.
Public Access 설정을 구성합니다. 이때 “Block all public access”를 선택 해제하고, 접근 제어 목록을 통한 액세스를 차단하는 두 가지 옵션을 선택합니다.
이 설정을 확인 후 새로운 버킷을 생성합니다.

4.2. S3 버킷 권한 구성

AWS 콘솔에서 “Identity and Access Management (IAM)”으로 이동합니다.
IAM 리소스 목록의 사용자 목록에서 이전 단계에서 생성했던 hyperlane-validator-${chain_name}와 같은 사용자의 ARN과 S3 버킷 ARN을 확인합니다,
확인한 사용자 ARN을 정보를 이용해 생성했던 S3 버킷의 “Bucket policy”를 변경합니다.
아래 버킷 정책(Bucket policy)예제를 참고하여 버킷에 알맞게 변경합니다.

버킷정책(Bucket Policy) 예제 (참고: AWS Signatures Bucket Setup)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "${BUCKET_ARN}",
                "${BUCKET_ARN}/*"
            ]
        },
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "${USER_ARN}"
            },
            "Action": [
                "s3:DeleteObject",
                "s3:PutObject"
            ],
            "Resource": "${BUCKET_ARN}/*"
        }
    ]
}

5. Docker Compose로 검증자 노드 실행하기

아래는 위에 언급한 AWS 설정을 통해 검증자 노드를 실행하기 위한 docker-compose 예제 파일입니다.

이 예제에서는 ethereum_validator.json 설정 파일을 사용합니다.

{
 "chains": {
   "ethereum": {
     "customRpcUrls": "https://node1.com,https://node2.com,https://node3.com"
   }
 },
 "originchainname": "ethereum",
 "validator": {
   "id": "alias/validator-signer-ethereum",
   "type": "aws",
   "region": "us-east-1"
 },
 "checkpointsyncer": {
   "bucket": "signatures-ethereum",
   "region": "us-east-1",
   "type": "s3"
 },
 "reorgperiod": 1,
 "interval": 30,
 "metrics": "9090"
}

Docker-compose.yaml 파일은 아래와 같습니다.

services:
 ethereum-validator:
   image: gcr.io/abacus-labs-dev/hyperlane-agent:3adc0e9-20240319-152359
   command: ./validator
   ports:
     - "9090:9090/tcp"
   environment:
     CONFIG_FILES: /ethereum_validator.json
     AWS_ACCESS_KEY_ID: somesecretkey
     AWS_SECRET_ACCESS_KEY: somesecretkey
   configs:
     - ethereum_validator.json
configs:
 ethereum_validator.json:
   file: ./ethereum_validator.json

해당 파일에는 다양한 설정 값들이 포함되어 있으며, 이는 각 체인과 용도에 따라 적절히 변경해야 합니다. 실제 운영을 위해서는 하이퍼레인의 공식문서의 Configuration reference를 참고 하시길 바랍니다.

검증자 노드 구축 시 필요한 RPC Endpoint는 공개 RPC 노드를 사용할 수 있지만, 공개 RPC 노드의 제약사항으로 인해 안정적인 인프라 운영과 유지관리가 어려울 수 있습니다. 안정성을 위해서는 신뢰할 수 있는 RPC 노드를 이용하거나 직접 RPC 노드를 구축하는 것을 추천합니다.

모니터링 및 경고 시스템 설정

검증자 노드를 운영하는 경우, 이 노드들이 정상적으로 작동하는지 모니터링하는 것이 중요합니다. 검증자 노드는 –metrics 인수로 지정된 포트 번호에서 다양한 지표를 제공합니다. 이 데이터를 Prometheus나 Grafana와 연동하면 실시간 모니터링 시스템을 구축할 수 있으며, 필요한 알림을 설정해 문제상황에 대응할 수 있습니다.

Hyperlane latest checkpoint metrics

Hyperlane block height sample metrics2

Hyperlane block height sample metrics

주요 모니터링 지표로는 다음과 같은 것들이 있습니다:

Hyperlane_latest_checkpoint: 이 지표는 검증자 노드가 제대로 검증을 수행했는지를 나타냅니다. 검증자는 phase=”validator_observed” 단계에서 checkpoint를 생성 및 저장하며 phase=”validator_processed” 단계에서 checkpoint를 검증 및 서명하여 hyperlane_latest_checkpoint를 최종적으로 업데이트 합니다. 따라서 위 세 지표들이 서로 동기화되지 않으며 단계적으로 업데이트되고 점진적으로 증가하고 있음을 확인해야 합니다.
hyperlane_block_height : 이 지표는 검증자 노드에 연결된 RPC 노드의 블록 높이를 나타냅니다. 검증자 노드는 블록체인의 최신 상태를 읽고 서명해야 하기 때문에 RPC 노드가 정상적으로 작동하고 있는지를 확인하는 것이 중요합니다. 블록 높이가 증가하지 않는것은 블록체인 네트워크 혹은 RPC 노드가 정상적으로 작동하고 있지 않다는 것을 의미합니다.

마무리

지금까지 하이퍼레인의 동작 원리와 검증자 역할을 살펴보고, DSRV가 AWS 환경에서 하이퍼레인 검증자를 안정적으로 구축하고 운영하는 방식에 대해서 살펴 보았습니다. 하이퍼레인에서는 네트워크 간 통신의 신뢰성을 보장하는 검증자 노드의 역할이 매우 중요하며, 이를 위해 DSRV는 AWS의 보안 서비스들을 활용하여 안전하고 효율적인 검증자 노드를 운영하고 있습니다. AWS IAM, AWS KMS, Amazon S3 등의 서비스를 통해 인증, 암호화, 데이터 저장 등의 기능을 제공하여 높은 수준의 보안성을 확보할 수 있었습니다.

블록체인 기술은 꾸준히 발전하고 있으며, 향후 계속해서 다양한 블록체인 네트워크 간의 상호운용성이 중요해질 것입니다. 하이퍼레인은 현재 35개 이상(공식 지원 체인은 15개, 비허가형 체인은 20개)의 블록체인의 상호 운용성을 제공하고 있습니다. 앞으로도 DSRV는 하이퍼레인 검증자로서 블록체인 생태계가 더욱 발전하고 상호운용성이 확대될 수 있도록 더 많은 기여를 해 나갈 계획입니다.

AWS 기술 블로그