4 디지털 에셋 API

Besu용 Oracle Blockchain Platform Enterprise Edition은 스마트 계약 작업에 사용할 수 있는 디지털 자산 API를 제공합니다.

디지털 자산 API는 Besu에서 디지털 자산 스마트 계약을 개발, 테스트 및 배포하기 위한 Solidity 기반의 재사용 가능한 구성 요소입니다. API를 사용하여 도메인별 토큰 애플리케이션을 구현하는 동시에 토큰 구성, ID 및 액세스 제어, 업그레이드 가능성 및 거버넌스에 대한 일관된 접근 방식을 유지할 수 있습니다.

모든 Oracle Blockchain Platform Besu 애플리케이션의 핵심은 디지털 자산의 상태와 생성, 전송, 보유, 상환 및 관리 방법을 제어하는 비즈니스 규칙을 정의하는 하나 이상의 스마트 계약입니다. 이러한 규칙은 자산 수명 주기에 직접적인 영향을 주므로 배포 전에 계약을 설계, 검토 및 테스트해야 합니다. 두 API는 각각 다른 토큰 표준을 지원합니다.

토큰 표준	기본 용도	예제 사용 사례
에르크-20	각 토큰이 다른 모든 토큰과 교환 가능한 자산입니다.	지불, stablecoins, 예금 토큰, 정착 토큰 및 도매 CBDC 자산.
에르크-1155	Fungible Assets 및 Non-fungible Assets(NFT) 동일한 스마트 계약에서 다중 토큰 유형이 지원됩니다. 분수 토큰(공유)이 지원됩니다.	토큰화된 자산, 수금 및 고유한 디지털 자산.

API는 구성 가능한 기본 계약 및 지원 라이브러리를 제공하여 사용자가 자체 Solidity 계약에서 상속 또는 작성할 수 있습니다. 선택한 토큰 모델에 따라 응용 프로그램에는 민트화 및 레코딩, 제어된 전송, 보류, 승인, ID 인식 권한 및 정책 적용과 같은 기능이 통합될 수 있습니다. 또한 API는 애플리케이션에 필요한 경우 업그레이드 가능한 계약 패턴 및 거버넌스 제어 수명 주기 작업을 지원합니다.

다음 다이어그램은 확장된 ERC-20 토큰 표준 구현의 기능을 보여줍니다.

다음 다이어그램은 확장된 ERC-1155token 표준 구현의 기능을 보여줍니다.

플러그인할 수 있는 액세스 제어 모듈

계정 및 정책 모듈을 선택하여 토큰 작업을 애플리케이션의 액세스 제어 모델에 맞출 수 있습니다. 특히 API에는 ERC-5982 및 EIP-6617 권한 모델에 대한 계약 및 계정 버전이 포함됩니다. 이러한 모듈은 토큰 계약을 ID 및 정책 게이트웨이에 연결하여 애플리케이션이 모든 토큰 계약에 단일 액세스 제어 구현을 포함하지 않고도 역할 인식 및 조직 인식 권한 부여를 적용할 수 있도록 합니다.

애플리케이션에 맞는 계정 변형 및 정책 기능을 선택한 다음 토큰 계약의 공통 계정 인터페이스를 사용할 수 있습니다. 이러한 분리는 토큰 비즈니스 논리를 자산 수명 주기에 중점을 두는 동시에 애플리케이션 요구 사항이 증가함에 따라 액세스 정책을 구성, 확장 또는 교환할 수 있도록 합니다.

계약 구성 모델

Solidity 토큰화 레이어는 계약 구성 모델을 사용합니다. 업그레이드 가능한 토큰 기반을 선택하고 자산 수명 주기에 필요한 동작 모듈을 추가한 다음 해당 토큰을 적절한 계정 및 액세스 제어 모듈과 쌍을 이룹니다. 이 모델은 모든 토큰이 모든 작업을 노출할 필요 없이 민트화, 레코딩, 보류 및 승인과 같은 기능을 지원합니다. 엄격한 컴포지션 또는 믹신/호환성 컴포지션을 사용할 수 있습니다.

디자인 시 지원되는 토큰 작업이 알려진 경우 엄격한 구성이 적합합니다. 개발자는 특정 기능만 지원하는 좁은 기본 계약에서 상속됩니다. 선택한 공정만 계약 ABI에 포함됩니다. 초기화 중 선택한 기능 프로파일에 대해 토큰 구성이 검증되므로 호환되지 않는 동작이나 민팅 및 레코딩 모드가 거부됩니다.

Mixin / 호환성 구성은 런타임 유연성과 더 광범위하고 재사용 가능한 토큰 작업 세트가 더 중요할 때 적합합니다. 개발자는 활성 상태인 선택적 정책을 결정하는 런타임 동작 플래그를 사용하여 전체 기본 계약에서 상속됩니다. 전체 ABI는 사용 가능한 상태로 유지되지만 동작 관련 작업은 호출될 때 사용으로 설정된 구성을 강제 적용합니다.

제품 요구 사항에 맞는 가장 좁은 구성을 선택한 다음 필요한 액세스 제어 계정 모듈 및 제품별 비즈니스 로직과 결합합니다. 엄격한 구성은 더 작고 의도적인 ABI를 생성하며 지원되지 않는 작업이 노출되지 않도록 합니다. Mixin/호환성 구성은 런타임 시 동작을 구성해야 하는 응용 프로그램에 대한 보다 광범위한 기반을 제공합니다.

API를 고정 응용 프로그램이 아닌 시작점으로 사용합니다. 일반적으로 팀은 필요한 자산 모델과 일치하는 ERC-20 또는 ERC-1155 기반을 선택하고, 동작 및 액세스 제어를 구성한 다음, 자산 수명 주기를 지원하는 특정 비즈니스 논리를 구현합니다. 이를 통해 공통 계약 기반을 구축하는 동시에 각 애플리케이션이 자체 참여자, 승인 규칙 및 운영 프로세스를 반영할 수 있습니다.

이 API는 ERC-20 및 ERC-1155 계약 소스와 직접 협력하는 Solidity 개발자를 위한 API입니다. Hardhat를 사용하여 애플리케이션을 개발 및 테스트한 다음 애플리케이션에 적합한 배포 접근 방식을 사용하여 Oracle Blockchain Platform 환경에 배포할 수 있습니다.

계약 배치 및 업그레이드를 위한 거버넌스 플로우

거버넌스는 배포된 계약이 사용 가능해지고 어떤 UUPS 구현 업그레이드가 승인되는지를 제어합니다. 구성된 프로젝트는 계정 및 토큰 프록시를 배포 및 연결한 다음 거버넌스 계약 및 거버넌스 UUID에 모두 연결합니다. 다음 수명 주기에 표시된 대로 구성된 거버넌스 플로우가 프록시를 활성화할 때까지 프록시가 의도적으로 비활성 상태입니다.

1. 계정 및 토큰 UUPS 프록시를 배치합니다.
2. 계정/토큰 컨텍스트 및 거버넌스 컨텍스트를 설정합니다. 프록시가 비활성 상태로 유지됩니다.
3. 프록시, 구현 및 코드 해시 구성요소를 사용하여 배포 의도를 제출합니다.
4. • No-Op: 구성 요소가 즉시 허용됩니다.
   • Governed: 정책 승인을 수집한 다음 승인 후 구성요소가 활성화됩니다.

거버넌스 모델

지원되는 두 거버넌스 모델은 No-Op 및 Governed입니다.

No-Op는 애플리케이션에서 거버넌스 수명 주기를 제거하지 않습니다. 동일한 거버넌스 인터페이스를 구현하고 의도를 기록하며 배포 및 업그레이드 검사를 자동으로 승인합니다. 생산 승인 메커니즘으로 No-Op 모델을 사용하지 마십시오.

관리 모델은 배포자, Blockchain App Builder 또는 CLI 스크립트가 승인자를 우회하도록 허용하지 않습니다. 필요한 승인자, 임계값, 기한 및 승인 프로세스는 배포된 거버넌스 및 정책 구성에 의해 정의됩니다.

다음 표에는 두 거버넌스 모델의 동작이 요약되어 있습니다.

거버넌스 모델	목적	배치 동작	업그레이드 동작
작업 없음	로컬 개발, 데모 및 거버넌스 승인이 의도적으로 우회되는 기타 상황입니다.	proposeDeployIntent 함수는 인텐트를 수락하고 해당 구성요소를 즉시 활성화합니다.	업그레이드 의도는 정책 승인 없이 수락됩니다. 운영자는 여전히 준비된 upgradeToAndCall 실행 단계를 실행합니다.
통제식	정책 기반 검토 및 승인이 필요한 환경입니다.	구성된 정책이 기한 전에 필요한 승인을 받을 때까지 인텐트는 보류 중인 상태로 유지되며, 그 후에만 구성요소가 활성화됩니다.	실행 단계에서 구현을 소비하고 프록시를 업그레이드하려면 제안된 구현 및 해당 코드 해시가 필요한 권한 부여를 받아야 합니다.

Blockchain App Builder로 프로젝트를 빌드할 때 다음 거버넌스 빌딩 블록이 이미 제공되었습니다.

• IDAContractGovernance 인터페이스와 NoOpGovernance 및 GovernedGovernance 구현입니다.
• setGovernanceContext, getGovernanceContext 및 activateFromGovernance 메소드를 포함하여 생성된 토큰 및 계정 계약 기반에 대한 거버넌스 컨텍스트 및 활성화 지원입니다.
• _authorizeUpgrade 프로세스 중 구성된 거버넌스 계약을 호출하는 API의 UpgradeAuthorizationLib 메소드를 통한 UUPS 업그레이드 승인입니다.
• 거버넌스 컨텍스트를 설정하고, 의도 데이터를 준비하고, 매니페스트를 기록하고, 의도 요청을 제출하는 생성된 배포 및 업그레이드 스크립트입니다.

이러한 빌딩 블록이 이미 제공되었으므로 표준 구성 프로젝트에서 생성된 토큰 및 계정 계약에 대해 추가 Solidity 거버넌스 후크를 작성할 필요가 없습니다. 여전히 적절한 거버넌스 계약을 선택 및 배포하거나 획득하고, UUID 및 정책을 구성하고, 배포/업그레이드 워크플로우에 주소를 제공하고, 관리되는 환경에 대한 승인 프로세스를 거쳐야 합니다. Oracle Blockchain Platform Besu 네트워크의 경우 인스턴스 프로비저닝의 일부로 거버넌스 계약이 배포됩니다.