블록체인 데이터 공유를 위한 분산 저장과 스마트 컨트랙트 설계

데이터 자체보다 검증과 권한을 온체인에 남긴다

데이터 공유에서 블록체인에 모든 원본을 올리는 방식은 저장 비용과 갱신·삭제 문제를 키운다. 실데이터는 분산 저장 네트워크에 보관하고, 블록체인에는 데이터의 해시(CID), 메타데이터, 접근 정책처럼 검증과 거래에 필요한 최소 정보만 기록하는 편이 현실적이다.

분산 데이터 저장은 콘텐츠 주소화(Content Addressing)를 기반으로 한다. IPFS, Filecoin, Arweave 같은 P2P 네트워크에 데이터를 저장하고 CID 또는 SHA-256 다이제스트로 동일성과 위·변조 여부를 확인한다.

스마트 컨트랙트는 공유 과정의 신뢰 경계를 자동화한다. 참여자의 신원과 권한, 가격·라이선스 정책, 조건부 지급, 이벤트 로그를 온체인 로직으로 집행한다. 이 구조에서는 온체인에 해시·머클 루트·정책을 두고, 오프체인에는 암호화된 실데이터와 암호키 관리 기능을 둔다.

저장소와 컨트랙트가 맡는 역할

온체인 저장은 불변성과 감사에는 유리하지만, 실데이터를 기록하면 저장 비용이 급격히 늘어난다. 따라서 실데이터 대신 해시나 루트값을 저장하는 방식이 권장된다.

오프체인 분산 저장은 IPFS/Filecoin/Arweave 등을 활용하며, 콘텐츠 해시로 데이터의 최종적 일관성을 검증한다. 다만 핀닝과 거버넌스 운영이 필요하다. 하이브리드 구조는 L2 합의와 해시 검증을 결합해 비용 대비 성능과 운영 유연성을 확보하는 선택지다.

스마트 컨트랙트 레지스트리에는 자산 등록, 가격 및 라이선스 정책, 접근 권한 매핑, 사용 로그 이벤트를 둔다. 토큰 또는 네이티브 결제, 즉시 정산 또는 에스크로, 환불·분쟁 처리 훅도 이 경계에서 정의한다.

데이터 동일성은 콘텐츠 주소화로 확인하며, 필요하면 머클 증명으로 부분 데이터를 검증할 수 있다. 권한 위임과 부인방지는 대칭 암호화와 수신자 공개키 암호, EIP-712 서명으로 구성한다.

개인정보보호 측면에서는 PII를 암호화·가명화하고 보존·파기 정책을 메타데이터화한다. 접근 로그와 동의 이력은 온체인에 영속화하되, 철회와 권한 회수 로직도 함께 둬야 한다.

데이터 제공부터 복호화까지의 흐름

⤢✕

구매 트랜잭션에서는 권한 부여와 정산을 원자적으로 처리하고 ReentrancyGuard를 적용한다. 수요자는 데이터를 받은 뒤 CID를 다시 검증하며, 검증 실패 시에는 분쟁 훅이나 에스크로 해제 조건을 활용할 수 있다. 암호키는 온체인에 공개하지 않고 오프체인 KMS 또는 프록시 리암호화(Proxy Re-encryption)로 관리한다.

의료·산업·연구 데이터에서의 적용 방식

의료 데이터 교환에서는 병원이 데이터를 탈식별화하고 암호화한 뒤 IPFS에 업로드한다. 이후 CID와 접근 정책을 등록한다. 연구기관은 스마트 컨트랙트로 결제하고 권한을 받은 다음 키를 수령해 데이터를 복호화·분석한다.

산업 IoT 데이터 마켓에서는 제조사가 센서 데이터 배치 단위의 머클 루트를 등록하고, 구매자별 사용량과 기간에 맞춘 라이선스를 제공할 수 있다. 구매자는 기간별 구독을 결제하고 만료 시 권한은 자동으로 회수된다.

연구 재현성 데이터 패키지에는 코드, 데이터, 환경 해시 번들을 등록할 수 있다. DOI 메타데이터와 온체인 레지스트리를 연결하면 연구 산출물의 인용과 감사를 쉽게 처리할 수 있다.

온체인·오프체인·하이브리드 선택 기준

전략	성능	확장성	일관성	안정성	운영 편의
온체인 저장	트랜잭션 지연·고비용	낮음	강한 일관성(블록파이널리티)	네트워크 수준 매우 높음	데이터 갱신·삭제 곤란
분산 오프체인(IPFS/Arweave)	고속 읽기/쓰기(노드 구성에 따름)	높음(P2P 확장)	콘텐츠 해시로 최종적 일관성	중복·영속성 옵션에 따름	핀닝/거버넌스 필요
하이브리드(L2+IPFS)	비용 대비 우수	매우 높음	L2 합의 + 해시 검증	L1 결제 보강 시 높음	운영 유연성 높음

컨트랙트에는 CID 해시와 정책만 기록한다

구현 환경은 Solidity ^0.8.20, Hardhat/Foundry, OpenZeppelin, EVM 호환 네트워크(L1/L2)를 전제로 한다. 데이터는 오프체인에서 암호화해 저장하고, 온체인에는 CID 해시와 정책만 남긴다. 민감 키와 평문 데이터는 온체인에 기록하지 않는다.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/security/ReentrancyGuard.sol";

contract DataShare is ReentrancyGuard {
    struct Asset {
        address owner;
        uint256 price;     // in wei or ERC-20는 별도 확장
        bool exists;
    }

    // key: keccak256(CID 문자열 또는 SHA-256 다이제스트를 bytes32로 맵핑)
    mapping(bytes32 => Asset) public assets;
    mapping(bytes32 => mapping(address => bool)) public accessGranted;

    event Registered(bytes32 indexed cidHash, address indexed owner, uint256 price);
    event Purchased(bytes32 indexed cidHash, address indexed buyer, uint256 price, bytes encryptedKeyRef);
    event AccessGranted(bytes32 indexed cidHash, address indexed grantee);

    function register(bytes32 cidHash, uint256 price) external {
        require(!assets[cidHash].exists, "already exists");
        assets[cidHash] = Asset({owner: msg.sender, price: price, exists: true});
        emit Registered(cidHash, msg.sender, price);
    }

    function updatePrice(bytes32 cidHash, uint256 newPrice) external {
        Asset storage a = assets[cidHash];
        require(a.owner == msg.sender, "not owner");
        a.price = newPrice;
    }

    // encryptedKeyRef: 온체인에 키 평문 저장 금지. 키 지시자/참조값(예: re-encryption 요청 토큰)만 기록 권장.
    function purchase(bytes32 cidHash, bytes calldata encryptedKeyRef) external payable nonReentrant {
        Asset storage a = assets[cidHash];
        require(a.exists, "not found");
        require(msg.value >= a.price, "insufficient payment");

        accessGranted[cidHash][msg.sender] = true;

        (bool ok, ) = a.owner.call{value: msg.value}("");
        require(ok, "payout failed");

        emit Purchased(cidHash, msg.sender, a.price, encryptedKeyRef);
        emit AccessGranted(cidHash, msg.sender);
    }
}

CID 계산은 multibase/multicodec 표준을 따르고 온체인에서는 bytes32로 축약해 저장한다. 결제 수단은 ERC-20으로 확장할 수 있으며, 에스크로와 분쟁 해결 로직도 추가할 수 있다. 이벤트에는 키 자체가 아니라 키 참조값만 기록하고, KMS 또는 프록시 리암호화가 소비자 공개키에 맞춰 키를 동적으로 전달하도록 구성한다.

개인정보, 키, 분쟁을 분리해 운영한다

PII는 암호화·가명화한 뒤 저장하고, 온체인에는 해시·정책·동의 이력만 남긴다. 온체인의 불변성 때문에 삭제권 이슈가 생길 수 있으므로, 실데이터는 오프체인에서 파기하고 온체인에는 철회 플래그와 접근 차단으로 대응한다.

키 관리는 HSM/KMS와 다자키(Shamir/Threshold)를 활용하고, 키 순환 및 폐기 정책을 명시한다. DID/VC 기반 신원을 연계하면 사업자 검증을 강화할 수 있다.

대량 등록과 로그는 L2·롤업 및 배치 처리로 가스 비용을 최적화한다. 게이트웨이 의존을 낮추기 위해 자체 IPFS 노드와 핀닝 서비스를 운영하는 방안도 고려한다.

정산은 에스크로와 머클 증명 또는 샘플 검증 조건을 조합할 수 있다. 오라클·중재 규칙은 온체인에 정의하고, 로열티 분배(스플릿), 재판매 정책, 환불 조건을 명확히 둔다. 재입금 공격은 ReentrancyGuard로 방지하며, 프런트러닝은 커밋-리빌·오프로딩으로 완화한다. 이벤트 로그에는 최소 메타데이터만 기록해 민감정보 노출을 줄인다.

비용·감사·수익화에서 얻는 변화

오프체인 분산 저장을 활용하면 온체인 직접 저장과 비교해 저장 비용을 10100배 이상 절감할 수 있다(네트워크·가스비 변동, 최신 정보 확인 필요). L2 배치 기록은 트랜잭션 비용을 550배 절감할 수 있다.

콘텐츠 주소화와 불변 로그는 위·변조 가능성을 현저히 낮추고 감사·추적 시간을 단축한다. 표준화된 컨트랙트와 분산 저장을 조합하면 파트너 온보딩 리드타임을 30~70% 단축할 수 있다. 자동 정산과 권한 부여는 계약에서 수익 실현까지 걸리는 시간을 분·시간 단위로 줄인다.

온체인에는 검증, 정책, 감사에 필요한 최소 정보만 남기고, 오프체인에는 암호화된 원본과 키 관리를 둬야 한다. L2, 에스크로, 프록시 리암호화, 표준화된 정책 모델을 함께 조합하면 데이터 공유 구조를 단계적으로 도입할 수 있다.