✨ HIP-551: 헤데라 배치 트랜잭션 도입

헤데라의 새로운 Batch Transactions (배치 트랜잭션) 기능은 엔터프라이즈급 트랜잭션 조합성을 네이티브 네트워크 서비스에 도입함으로써, 개발자들이 탈중앙화 애플리케이션을 구축하는 방식을 변화시킵니다.

이 기능은 이전에는 스마트 컨트랙트가 필요했던 정교한 워크플로우를 하나의 트랜잭션에서 가능하도록 하며, 트랜잭션 무결성과 대규모 성능을 모두 요구하는 애플리케이션을 위한 최적의 플랫폼으로서 헤데라를 위치시킵니다.

⚡ Batch Transactions의 힘

HIP-551: Batch Transactions의 구현을 통해, 이제 헤데라 네트워크는 개발자들이 하나의 원자적(atomic) 트랜잭션으로 여러 작업을 ACID (Atomicity, Consistency, Isolation, Durability) 특성을 갖고 실행할 수 있도록 합니다.

복잡한 다단계 작업은 전부 완전히 수행되거나, 전부 실패되며, 부분 실행으로 인해 불일치한 상태나 보안 취약점이 생기는 시나리오를 제거하게 되며, 이를 통해 스마트 컨트랙트 없이도 서로 다른 헤데라 서비스 간의 원자적 실행을 가능하게 하며, 개발 워크플로우를 크게 단순화하면서도 보안성과 사용자 경험을 동시에 향상기키게 됩니다.

즉, 배치 트랜잭션은 정교한 탈중앙화 애플리케이션에 필요한 원자성 보장을 제공하면서도 헤데라의 성능 이점을 그대로 유지합니다.

이제 HIP-551을 자세히 살펴보고, 이것이 사용자와 개발자에게 무엇을 의미하는지 알아보도록 하겠습니다.

🔍 HIP-551 한눈에 보기: 원자적 트랜잭션 실행 가능하게 만들기

Batch Transactions은 개발자들이 여러 트랜잭션을 “하나의 원자적(atomic) 작업” 으로 묶어, 전체가 하나의 단위로 성공하거나 실패하도록 할 수 있게 합니다.

즉, 이 기능은 상호 의존적인 HAPI 호출들의 연속을 일관성 있게 실행할 수 있다는 의미이며, 모든 변경 사항이 함께 적용되거나 전혀 적용되지 않도록 보장하여 안전한 다단계 워크플로우의 개발과 실행을 가능하게 합니다.

✅ 올오어낫싱(All-or-Nothing) 트랜잭션 실행: 시스템이 불일치한 상태로 남을 수 있는 부분 완료 상황을 제거하여 더 탄탄한 애플리케이션을 만들수 있도록 합니다.
✅ 개발자 워크플로우 단순화: 다단계 작업이 이제 별도의 트랜잭션 간 수동 조정 없이도 가능해 집니다.
✅ 다단계 트랜잭션 보안 강화: BatchKey 메커니즘을 통해 승인된 엔티티만 트랜잭션 배치를 구성하고 제출할 수 있도록 합니다.
✅ 샌드위치 공격 제거: 악의적인 행위자가 관련된 트랜잭션 사이에 새로운 트랜잭션을 삽입하는 것을 방지합니다.

이제 이 새로운 기능의 핵심 요소들을 더 깊이 탐구해 보도록 하겠습니다.

🧩 핵심 기능 (Key Features)

배치 트랜잭션은 개발자가 헤데라에서 복잡한 작업 또는 워크플로우를 구성하는 방식을 변화시키는 여러 강력한 기능을 도입합니다. 이 구현의 핵심에는 보안, 유연성, 성능을 균형 있게 고려한 아키텍처가 있으며, 정제된 사용자 및 개발자 경험을 제공합니다.

1) 🔒 트랜잭션 무결성: ‘자급자족(Self-Contained) 단위’ 원칙

트랜잭션 무결성은 배치 내부의 각 내재(Inner) 트랜잭션이 자급자족하는 단위로 동작하도록 보장합니다. 이 트랜잭션들은 개별 무결성을 유지하지만, 원자적 단위의 일부로 실행되어 모두 성공하거나 모두 실패합니다. 이 설계는 익숙한 트랜잭션 모델을 유지하면서도 강력한 트랜잭션 조합 능력을 추가합니다.

2) 🗝️ BatchKey 보안: 신뢰의 체인 생성

새롭게 도입된 BatchKey는 악의적 행위자가 트랜잭션 배치를 변조하는 것을 방지합니다. 이 키는 배치를 최종 확정할 수 있는 신뢰된 서명자를 나타내며, 트랜잭션들이 완전한 단위로만 제출되도록 보장하고, 의도된 컨텍스트 밖에서 개별 작업이 실행되는 것을 막습니다. 모든 내재 트랜잭션은 BatchKey를 포함해야 하며, 외부(Outer) 배치 트랜잭션은 지정된 모든 BatchKey로 서명되어 신뢰의 체인을 형성합니다.

3) 🧱 중첩 구조: Inner vs Outer 트랜잭션 모델

Inner 트랜잭션은 개별 서명, 자기 비용 지불, 자체 권한 요구사항을 유지합니다. 반면, 외부(AtomicBatch) 트랜잭션은 별도의 지불자와 서명을 가지며, 내부 트랜잭션들을 서명 바이트에 포함합니다. 이 중첩 구조는 헤데라의 기존 보안 모델을 유지하면서 원자적 실행을 가능하게 합니다.

4) 🧪 원자적 처리: 일관된 상태 전이를 보장

배치 트랜잭션 처리는 모든 트랜잭션이 성공해야만 커밋되는 일관된 모델을 따릅니다. 어떤 내재 트랜잭션이라도 실패하면 전체 배치가 롤백됩니다. 다만 처리된 트랜잭션의 수수료는 여전히 부과됩니다. 이 구현은 일관된 상태 전이를 보장하면서도 헤데라의 경제 모델을 유지합니다.

5) 🧮 투명한 경제성: 수수료 관리 방식

수수료 관리는 각 내재 트랜잭션의 유형에 따라 개별적으로 부과되어 명확성과 예측 가능성을 유지합니다. 또한 외부 배치 트랜잭션 자체에도 배치를 처리하는 데 필요한 별도의 수수료가 부과됩니다. 이는 제공되는 가치에 정렬된 투명한 비용 구조를 형성합니다.

이러한 기능들이 결합되어, 하위 호환성을 유지하면서도 복잡한 워크플로우 구현을 대폭 확장하는 원자적 트랜잭션 실행을 위한 견고한 프레임워크를 제공합니다.

🚀 실용적 활용 사례: 헤데라 개발 방식을 혁신하다

HIP-551은 과거에는 스마트 컨트랙트 없이는 구현하기 매우 복잡하거나 사실상 불가능했던 광범위한 사용 사례들을 가능하게 합니다.

✅ 1. 계정-바운드 토큰 (Account-bound Tokens)

계정을 언프리즈(unfreeze) 하고, 토큰(대체 가능 및 대체 불가능)을 전송한 뒤, 즉시 계정을 다시 프리즈(freeze) 하는 과정을 단일 원자적 트랜잭션으로 수행함으로써, 사용자와 개발자는 진정한 의미의 양도 불가능한 디지털 자산 (soulbound tokens) 을 만들 수 있습니다.

🎓 예시 애플리케이션: 한 대학교가 디지털 졸업장을 발급할 때, 해당 자격 증명이 졸업자의 검증된 지갑에 영구적으로 연결된 상태로 유지되어야 합니다.

🔄 2. 복합 토큰 흐름 (Complex Token Flows)

토큰 삭제(wiping), 발행(minting), 전송(transferring) 과 같은 여러 토큰 작업을 단일 원자적 트랜잭션으로 결합합니다. 이는 특히 규제 준수 또는 복잡한 재무(트레저리) 운영에 매우 유용합니다.

💱 예시 애플리케이션: 스테이블코인 발행자가 중단 없이 이어지는 트랜잭션 시퀀스로 준수 가능한 토큰 업그레이드를 수행해야 할 때, 원자적 배치 트랜잭션을 사용해 “이전 토큰을 삭제 → 새 토큰을 발행 → 동일한 계정에 전송”을 하나의 배치 안에서 실행하여 부분 실행의 위험 없이 완전한 업그레이드를 달성할 수 있습니다.

🔗 3. 교차 서비스 작업 (Cross-Service Operations)

서로 다른 Hedera 서비스 간 작업을 하나의 단일 트랜잭션에서 실행할 수 있습니다. 예: 토큰을 전송하면서 동시에 해당 전송 내역을 컨센서스 토픽에 기록.

📦 예시 애플리케이션: 공급망(supply chain) 애플리케이션은 자산(토큰)의 소유권을 업데이트하는 동시에 전체 트랜잭션 이력을 변경 불가능한 HCS 토픽에 기록하여 자산 상태와 문서화 간 완벽한 정합성 (alignment) 을 보장할 수 있습니다.

🛡️ 4. 컴플라이언스 작업 (Compliance Operations)

규제 준수를 위한 강력한 컴플라이언스 워크플로우를 단일 배치로 구현할 수 있습니다.

예를 들어, 배치 트랜잭션을 사용하면 “✅ KYC 부여 → ✅ 토큰 전송 → ✅ 이후 KYC 해제”를 단일 원자적 작업으로 처리할 수 있으며, 이 방식은 KYC가 해제된 계정이 토큰 삭제 이전에 토큰을 전송해버리는 상황을 방지하여 잠재적인 규제 공백(compliance gaps) 을 완전히 제거합니다.

📊 예시 애플리케이션: 토큰화된 증권 플랫폼이 ”KYC 부여 → 토큰 전송 → KYC 철회”를 원자적으로 실행하여 규제에 준수되지 않는 상태가 발생할 여지를 차단합니다.

✅ 5. 승인 워크플로우 (Approval Workflows)

BatchKey 메커니즘을 활용하여 안전한 다중 승인(multi-party approval) 프로세스를 구현할 수 있습니다. 기업 재무(treasury) 운영 등에서 여러 승인자가 필요한 경우, 배치 트랜잭션은 필요한 모든 승인(sign-off) 이 완료되기 전까지 어떠한 작업도 실행되지 않도록 보장합니다.

🏛️ 예시 애플리케이션: DAO 재무 관리 시스템에서 특정 승인 워크플로우를 모두 거친 후에만 토큰 전송이 실행되어야 할 때, 배치 트랜잭션을 사용하면 모든 승인 + 전송이 원자적으로 한 번에 실행됩니다.

✅ 이처럼, 배치 트랜잭션은 스마트 컨트랙트 없이도 헤데라 네이티브 서비스만으로 정교하고 안전한 워크플로우를 구현할 수 있게 합니다. 즉, 복잡성 감소, 예측 가능성 증가, 보안 강화라는 세 가지 이점을 동시에 제공합니다.

👨‍💻 Developer Guide (개발자 가이드)

이제 Hedera SDK를 사용하여 배치 트랜잭션을 구성하고 실행하는 방법을 코드 스니펫을 통해 살펴보겠습니다.

이 시나리오에서는 하나의 원자적 트랜잭션 안에서 다음 작업들을 모두 수행합니다:

✅ NFT 발행 (mint)
✅ 퍼지블 토큰을 여러 계정에 분배
✅ 토큰 일시 중지 (pause)
✅ 컨센서스 토픽에 메시지 제출 (HCS)

즉, 완전히 성공하거나 완전히 실패하는 단일 배치로 실행됩니다.

🧭 구현 흐름 (단계별)

1️ .batchify() 를 사용하여 배치 구성 설정이 포함된 NFT 민트 트랜잭션을 준비한다.

2️ 여러 수신자에게 퍼지블 토큰을 분배하는 토큰 전송 트랜잭션을 준비한다.

3️ 토큰 작업을 중단하기 위한 토큰 pause 트랜잭션을 준비한다.

4️ 작업 내역을 온체인에 기록하기 위한 컨센서스 메시지 트랜잭션을 준비한다.

5️ 준비된 모든 트랜잭션을 하나의 원자적 배치로 구성한다.

6️ 배치 트랜잭션을 네트워크에 실행한다.

7️ 전체 배치 실행 상태를 조회하고 표시한다.

8️ 각 내부 트랜잭션의 영수증(receipt)을 조회하여 개별 작업 결과를 검증한다.

🔧 핵심 개념 요약

이 예제는 배치 트랜잭션을 구현하는 핵심 워크플로우를 보여줍니다.

각 개별 트랜잭션은 .batchify() 메서드를 사용하여 준비됩니다. → 이 메서드는 해당 트랜잭션을 배치에 포함시키기 위해 적절한 BatchKey와 node account marker를 설정합니다.
이렇게 준비된 트랜잭션들은 BatchTransaction 객체에 추가되며, 이 객체가 원자적 실행을 처리합니다.
실행 이후, 개발자는 전체 배치의 Receipt와 각 Inner 트랜잭션의 Receipt를 모두 조회하여 전체 성공 여부 + 개별 성공 여부를 완전히 가시적으로 확인할 수 있습니다.

👉 그러면서도 여전히 모든 작업은 함께 성공하거나 함께 실패한다는 “원자성 보장”은 그대로 유지됩니다.

🧠 기술적 구현 (Technical Implementation)

배치 트랜잭션의 기술적 설계는 유연성, 보안성, 그리고 하위 호환성 사이에서 매우 신중한 균형을 이루고 있습니다.

핵심적으로, 이 구현은 여러 개의 내부 트랜잭션 (inner transactions) 을 포함할 수 있는 새로운 AtomicBatchTransactionBody 를 도입하며, 이를 단일 원자적 단위로 실행합니다.

이 구조는 개별 트랜잭션의 무결성을 유지하면서도, 그들이 하나의 그룹으로 함께 성공하거나 함께 실패하도록 보장합니다.

✅ 내부 트랜잭션의 특징

각 Inner 트랜잭션은 배치 내부에서도 자신만의 무결성을 유지합니다:

자체 서명(signatures) 보유
자체 수수료(fees) 지불
자체 권한 요구사항(authorization requirements) 유지

즉, 기존 헤데라 트랜잭션 모델을 그대로 유지하면서도, 원자적 조합을 가능하게 하는 방식입니다.

🔐 배치에 포함되기 위한 조건

Inner 트랜잭션이 배치의 일부로 지정되려면 다음을 수행해야 합니다:

✅ nodeAccountID 값을 0.0.0 으로 설정 (특수 마커 값)
✅ batchKey 반드시 포함 (보안 핵심 요소)

batchKey는 배치를 조립하고 제출할 권한이 있는 신뢰된 엔티티를 지정하므로 매우 중요합니다.

🧾 외부(Outer) 배치 트랜잭션의 역할

외부 배치 트랜잭션은 모든 Inner 트랜잭션에서 지정한 batchKey 서명자들에 의해 서명되어야 합니다. 이 과정을 통해 신뢰의 체인(chain of trust) 이 형성됩니다.

✅ 요약하면:

각 내부 트랜잭션은 여전히 자신만의 서명, 수수료, 권한 요구사항을 유지하지만, nodeAccountID=0.0.0과 batchKey를 포함함으로써 “이 트랜잭션은 배치의 일부”임을 명확히 표시합니다. 그리고 외부 배치 트랜잭션은 모든 batchKey를 가진 주체들이 서명함으로써 전체 배치의 정당성과 신뢰성을 보장합니다. 즉, 내부 트랜잭션은 독립성을 유지하면서도, 외부 트랜잭션을 통해 하나의 원자적 단위로 묶여 실행되는 구조입니다.

💻 Code Snippet (코드 구조 및 처리 규칙)

이 아키텍처는 배치 트랜잭션을 처리하기 위해 명확한 규칙들을 포함하고 있으며, 이를 통해 실행 동작을 예측 가능하고 안정적으로 유지합니다.

✅ 내부 트랜잭션에 적용되는 제약 사항

내부(Inner) 트랜잭션은 다음과 같은 제한을 가집니다:

내부 트랜잭션 자체가 또 다른 배치 트랜잭션일 수 없음
배치 내에서 각 트랜잭션은 고유한(transaction ID) 값을 가져야 함
내부 트랜잭션은 예약(Scheduled) 트랜잭션일 수 없음

👉 이러한 제약을 둠으로써 실행 순서와 동작이 예측 가능하고 일관성 있게 유지됩니다.

🔁 실행 방식: 순차 처리 + 영수증(Receipt) 생성

배치가 실행될 때, 내부 트랜잭션들은 순서대로 하나씩 처리되며 각각 자신의 트랜잭션 영수증(receipt) 과 레코드(record) 를 생성합니다.

하지만 중요한 점!

내부 트랜잭션 중 하나라도 실패하면 전체 배치는 롤백됩니다.
단, 이미 처리된 트랜잭션에 대한 수수료는 그대로 청구됩니다. (경제 모델 유지)

💰 수수료 처리 원칙 (Transparent Fee Model)

수수료는 매우 명확하고 예측 가능하게 처리됩니다:

✅ 각 내부 트랜잭션은 자신의 유형에 따라 수수료를 개별적으로 지불
✅ 외부 배치 트랜잭션도 별도의 수수료를 지불 (배치 전체를 처리하기 위한 비용)

👉 따라서 내부 + 외부 수수료가 모두 존재하며, 이는 “제공되는 가치에 비례하는 정직한 비용 구조”를 형성합니다.

📏 배치 크기 제한 (Batch Size Limits)

안정성과 성능을 위해 배치에는 다음과 같은 제한이 있습니다:

트랜잭션 개수: 최대 50개의 child 트랜잭션 (현재 설정 기준 및 구성값에 따라 결정)
전체 byte 크기: 최대 6KB (기존 트랜잭션 최대 크기와 동일)

🔍 Mirror Node API에서의 추적 가능성

Mirror Node API를 사용할 때, 배치 트랜잭션은 완전히 추적 가능합니다.

각 내부 트랜잭션의 레코드에는

parentConsensusTimestamp가 포함되어
이것이 해당 트랜잭션이 어떤 배치(부모)에 속하는지 연결(link) 합니다.

✅ 이로 인해 완전한 감사(audit) 가능성이 확보되며, 개발자는 트랜잭션 간의 관계를 명확하게 파악할 수 있습니다.

🧱 SDK 지원: BatchTransaction 클래스

SDK 설계에는 새로운 BatchTransaction 클래스가 포함됩니다. 이를 통해 개발자는 익숙한 API 패턴을 유지하면서도 트랜잭션들을 손쉽게 원자적 배치로 구성할 수 있습니다.

🌍 생태계 영향 및 미래 방향

배치 트랜잭션은 스마트 컨트랙트 없이도 복잡한 다단계 작업을 실행할 수 있게 함으로써, 헤데라를 블록체인 상호운용성과 개발자 경험의 최전선에 위치시킵니다. 이 기능은 헤데라의 네이티브 서비스로 정교한 비즈니스 로직을 구현할 수 있게 만들어주며, 강력한 원자성(atomicity) 보장을 제공합니다.