면책 조항: 이 Marlowe Security 문서의 내용은 어떤 종류의 보장도 없이 “있는 그대로” 제공됩니다. 이 문서의 어떠한 내용도 재정, 투자, 법률 또는 세금 조언을 포함하되 이에 국한되지 않는 전문적인 조언을 제공하기 위한 것이 아닙니다. Input Output Global은 이 문서의 정보 사용 또는 의존에 대해 책임을 지지 않습니다.
소개
대부분의 블록체인에서 스마트 계약은 특정 사전 정의된 조건이 충족되면 자체 실행되는 컴퓨터 프로그램입니다. Cardano에서는 스마트 계약 실행이 Cardano 노드에 외부적으로 제출된 트랜잭션에서 발생하기 때문에 조금 다릅니다. 그러나 내부적으로 작동하는 방식에 관계없이 스마트 계약은 금융, 부동산, 상업 및 기타 여러 산업에 유용합니다.
스마트 계약을 사용하는 거래에는 상당한 가치의 이동 및 이전이 포함될 수 있으며, 이는 나쁜 행위자의 소중한 목표가 될 수 있습니다. 마찬가지로 이 값은 코딩의 결함이나 취약성으로 인해 잠기거나 완전히 손실될 수 있습니다.
원하지 않는 결과를 피하려면 개발자, 교환 및 스마트 계약을 처리하는 다른 당사자의 설계 원칙, 감사 및 모범 사례의 조합을 포함하는 강력한 보안 프레임워크의 구현이 필요합니다.
Marlowe는 Cardano의 기술 커뮤니티 전반에서 계속 증가하는 다양한 리소스에 추가되어 Cardano 블록체인에서 금융 및 거래 스마트 계약을 개발할 수 있도록 IOG(Input Output Global)에서 만든 도구 및 언어의 생태계입니다.
Marlowe 제품군은 보안 중심에 중점을 두고 설계 및 개발되었습니다. Marlowe의 제작자는 예를 들어 계약이 유한하고 항상 종료되도록 하는 기능 제한을 내장했습니다. Marlowe는 또한 재귀 및 반복과 같은 원하지 않는 결과를 방지하기 위해 특정 프로그래밍 구조를 피합니다. 타사인 Tweag는 Marlowe가 메인넷에 배포되기 전에 정적 및 동적 감사를 수행했습니다. 이러한 모든 보안 기능과 다른 많은 기능의 결과는 안전하고 안전한 스마트 계약 생성 및 개발 플랫폼입니다.
이 문서에서는 Marlowe의 보안에 대해 자세히 설명하고 보안 감사 결과와 팀이 이에 대응한 방법, 기본 제공 기능 제한, 배포에 포함된 보안 분석 도구, Marlowe를 사용할 때 취해야 하는 몇 가지 예방 조치 및 고려 사항을 설명합니다.
이 문서의 구조
이 문서는 명확하게 정의된 6개의 섹션으로 나뉩니다.
- 스마트 계약 감사
- 스마트 계약 기반 공격
- Tweag 감사
- Marlowe의 기본 제공 보안 강화 기능 제한
- 거래 검증
- 통화 정책
전체적으로 이 문서는 Marlowe 도구 모음이 어떻게 감사 및 강력한 보안 원칙을 활용하여 안전하고 안전한 스마트 계약 개발 환경을 유지합니다.
스마트 계약 감사
개요
스마트 계약의 고유한 자율성과 특정 거래에 관련된 상대적으로 높은 지분은 일관성과 보안을 보장하는 것이 무엇보다 중요하다는 것을 의미합니다. 이를 위해서는 잠재적인 결함이나 의도적인 악성 코드를 감지하고 해결할 수 있도록 스마트 계약이 실행될 때 어떻게 작동하는지 정확히 알아야 합니다. 보안 관점에서 스마트 계약을 감사하는 것은 후속 실패 또는 손상을 방지하는 가장 좋은 방법입니다. 감사는 배포 전에 스마트 계약의 코드와 조건을 철저히 검사하여 계약이 예상대로 작동하는지 확인합니다.
감사 방법
스마트 계약 감사에 대한 접근 방식은 프로젝트마다 다를 수 있지만 수동 또는 자동 방법을 사용하여 스마트 계약을 분석할 수 있습니다. 일반적으로 대부분의 프로젝트는 두 가지를 조합하여 사용합니다.
문서 수집
감사 프로세스가 시작되기 전에 감사자는 프로젝트 관련 문서를 수집하는 데 시간을 할애할 수 있습니다. 여기에는 기술 문서, 백서, 코드베이스 및 감사 프로세스에 관련되고 도움이 될 수 있는 기타 자료가 포함될 수 있습니다.
수동 감사
이러한 형태의 스마트 계약 감사에는 각 코드 라인, 계약 논리, 계약 아키텍처 및 내장된 보안 조치를 분석하여 효율적인 설계와 정확성을 보장하는 사람들 그룹이 포함됩니다. 코딩 오류를 밝히는 것 외에도 수동 감사는 설계 결함을 발견할 수도 있습니다. 수동 감사는 매우 철저하고 정확한 방법으로 간주되는 경향이 있습니다.
자동화된 감사
수동 감사와 달리 자동 감사는 일반적으로 소프트웨어 중심의 테스트 접근 방식을 취합니다. 독점 또는 상용 소프트웨어 감사 도구는 버그를 감지하는 데 도움이 될 수 있지만 특정 취약성은 명백하지 않을 수 있습니다.
이러한 방법의 상호 보완적인 특성으로 인해 최상의 감사 방법에는 수동 및 자동 감사의 조합이 포함되어 잠재적인 모든 결함, 버그 및 취약성을 감지하고 수정합니다.
감사 후 조치
감사 프로세스가 완료되면 감사자는 발견한 내용을 자세히 설명하는 보고서를 생성합니다. 여기에는 심각도별 오류 분류 및 일련의 권장 사항이 포함될 수 있습니다.
계약 오류는 다음과 같이 분류할 수 있습니다.
- 중요: 이러한 유형의 결함은 계약 및/또는 프로토콜의 안전한 기능을 방해할 수 있습니다.
- 주요: 코딩 또는 논리의 특정 오류는 자금 손실 또는 제어되지 않는 프로토콜 상태로 이어질 수 있습니다.
- 중간: 자금이 위험하지 않을 수 있지만 이러한 유형의 오류는 계약의 성능이나 신뢰성에 영향을 미칠 수 있습니다.
- 경미: 이 분류에는 일반적으로 보안에 거의 또는 전혀 영향을 미치지 않는 비효율적인 코드가 포함됩니다. 정보: 일반적으로 코딩 스타일 또는 모범 사례 문제를 나타냅니다.
스마트 계약 감사의 장점
감사는 모든 애플리케이션에 중요하지만 이러한 분산 원장의 불변 특성 때문에 블록체인에서 실행되는 스마트 계약 및 분산 애플리케이션(DApp)에 특히 중요합니다.
스마트 계약 감사의 장점에는 사전 예방적 위험 식별, 잠재적으로 비용이 많이 드는 오류 방지, 전반적으로 더 나은 개발 환경, 취약성에 대한 통찰력 확보 및 이를 제거하는 방법이 포함됩니다.
사전 위험 식별
감사되지 않은 스마트 계약의 배포는 개발자나 회사가 절대 해서는 안 되는 도박입니다. 일부 스마트 계약에는 상당한 자금이 포함될 수 있으며, 손실되거나 손상될 경우 더 큰 부채로 이어질 수 있습니다. 이러한 위험을 사전에 해결하기 위해 노력함으로써 무언가 잘못될 가능성이 크게 줄어듭니다.
잠재적으로 비용이 많이 드는 오류 방지
코딩/로직 오류로 인해 또는 계약에 대한 악의적인 간섭으로 인해 자금이 영원히 잠기는 것은 고객이나 개발자가 경험하기를 원하지 않는 것입니다. 금전적 손실은 한쪽에 불과합니다. 또한 심각한 법적 문제가 발생할 수 있습니다.
전반적으로 더 나은 개발 환경
감사 소프트웨어는 권장 사항일 뿐만 아니라 필수 사항입니다. 애플리케이션 또는 애플리케이션 제품군의 보안을 보장하고 모범 사례를 따르면 서비스가 강화되고 보다 건전한 개발 환경이 조성됩니다.
취약점에 대한 통찰력 확보 및 이를 제거하는 방법
소프트웨어 개발에서는 예방이 패칭보다 낫습니다. 그리고 스마트 계약의 경우 블록체인의 불변성 때문에 패치할 기회가 없습니다. 철저한 감사를 통해 코드, 계약 논리, 아키텍처 및 기타 여러 매개 변수에 대한 많은 정보를 얻을 수 있으므로 개발자가 가능한 최상의 계약을 수정하고 생성할 수 있습니다.
스마트 계약 기반 공격
재진입 공격
이 공격에서 스마트 컨트랙트 기능은 두 번째 컨트랙트를 호출하여 트랜잭션 제어를 일시적으로 포기합니다. 이 컨트랙트는 첫 번째 컨트랙트에 대한 재귀 인출 호출을 시작하고 첫 번째 컨트랙트가 상태를 업데이트하기 전에 자금을 소모합니다. 이러한 유형의 공격은 스마트 계약 코딩의 버그로 인해 가능해집니다. 2016 DAO 이벤트에는 재진입 공격이 포함되었습니다.
Cardano 블록체인의 설계는 재진입 공격을 불가능하게 만듭니다. Cardano는 EUTXO 모델을 사용하기 때문에 스마트 계약은 원자적이며 서로 호출하지 않으므로 재진입이 불가능합니다.
선행 침략
일부 블록체인 설계에서는 온체인에서 확인되기 전에 스마트 계약 및 트랜잭션을 한동안 공개적으로 볼 수 있습니다. 이러한 보류 중인 거래는 네트워크 전체의 멤풀에서 공유되므로 상대방이 의도한 계약 결과를 볼 수 있습니다. 계류 중인 거래에 대한 가시성이 있는 그러한 상대는 그렇게 하면 다른 사용자의 이익을 희생시키면서 계류 중인 거래를 기반으로 이익을 얻을 수 있다는 것을 알고 새로운 거래 또는 거래를 도입할 수 있습니다. 본질적으로 공격자는 트랜잭션의 실행 순서를 자신에게 유리하게 조작합니다.
이러한 유형의 이벤트는 다른 블록체인에서 큰 문제가 되지만 Cardano(그리고 더 나아가 Marlowe)가 전면 실행 침입에 취약할 것이라는 증거는 없습니다.
오라클 조작
오라클은 블록체인을 외부 시스템에 연결하고 스마트 계약은 오라클에서 받은 데이터를 기반으로 실행될 수 있습니다. 외부 시스템에 대한 이러한 의존성은 오라클이 받은 입력이 오라클에 공급되기 전에 조작된 경우 스마트 계약 실행의 보안 및 무결성이 손상될 수 있음을 의미합니다.
다른 일반적인 스마트 계약 기반 보안 취약성에는 산술 오류, 정수 오버플로 및 언더플로, 스마트 계약 가시성 설정 및 타임스탬프 조작이 포함됩니다.
Tweag 감사
이 섹션에서는 Tweag 보안 감사의 결과, Marlowe 팀의 응답 및 Marlowe 설계에 구축된 보안 원칙에 중점을 둡니다.
Tweag 보안 감사 및 내부 대응의 주요 결과
Tweag는 Marlowe 언어에 대한 수동 및 자동 감사를 수행하여 몇 가지 문제를 드러냈습니다.
심각도가 높은 결과에는 음수 예금 처리, ‘이중 만족’ 방지, 상태 불변의 시행, 공식 사양과 Plutus 구현 간의 구현 차이, 자금 보존 정리 증명이 포함되었습니다.
마이너스 예금 처리
예금 수입은 음수인지 여부에 관계없이 예금 입력을 합산하여 계산되지만 시맨틱은 예금을 0으로 간주합니다. 종료 Marlowe 상태에 대한 잔액 확인이 없는 것과 결합하여 종료 잔액이 Marlowe 검증자에게 지불된 값과 다를 수 있습니다. 이는 마이너스 예금을 허용하는 Marlowe 계약에 의해 악용될 수 있습니다.
내부 대응
이 문제는 Marlowe 시맨틱 유효성 검사기에서 음수 예금에 대한 가드를 추가하여 해결되었습니다. 이 가드는 음수 예금에 대한 유효성 검사기의 의미 체계가 Marlowe의 Isabelle 의미 체계와 일치하도록 합니다. 구체적으로, 음수 수량의 예치금은 0 예치금으로 취급됩니다. 따라서 마이너스 예금은 Plutus 데이텀의 계정 잔액을 감소시키지 않으며 내부 잔액의 합계는 UTXO에 보유된 값과 Marlowe 의미론 스크립트 주소와 일치합니다.
이중 만족 방지
Marlowe 유효성 검사기는 동일한 트랜잭션에서 실행되는 Marlowe 유효성 검사기 스크립트의 여러 복사본 사이에서 이중 만족을 방지했지만 Marlowe 유효성 검사기가 동일한 트랜잭션에서 다른 Plutus 유효성 검사기와 함께 실행되는 경우에는 이를 방지하지 못했습니다.
내부 대응
이제 Marlowe 유효성 검사기가 당사자에게 지불하는 트랜잭션 중에 실행되는 유일한 Plutus 스크립트임을 적용하여 이중 만족을 방지합니다. 이를 통해 Marlowe 계약은 다른 Plutus 스크립트와 조정할 수 있지만 이중 만족이 불가능한 조건에서만 가능합니다. 이 완화의 정확성을 확인하기 위해 일부 속성 기반 테스트가 추가되었습니다.
상태 불변의 시행
원래 Marlowe 검증자는 자신의 올바른 작동에 대해 낙관적인 가정을 하고 Plutus 실행 비용을 줄이기 위해 특정 불변량을 확인하지 않았습니다.
내부 대응
Marlowe 시맨틱 유효성 검사기는 이제 초기 및 최종 상태에 대한 불변성을 엄격하게 적용하여 긍정적인 계정의 세 가지 상태 불변, 상태 항목의 비중복(계정, 선택 및 바운드 값) 및 총 내부 값이 스크립트 UTXO의 값.
공식 사양과 Plutus 구현 간의 구현 차이점
감사 결과 공식 사양과 실제 Plutus 구현 간에 약간의 차이점이 드러났습니다. 특히 Isabelle, Haskell 및 Plutus Tx와 관련된 언어 차이 및 효율성 고려 사항입니다.
형식 사양은 형식 메서드용 언어인 Isabelle로 작성되고 실제 Marlowe 구현은 Haskell 및 Plutus Tx로 작성됩니다. Marlowe 팀은 최대한 Isabelle 사양을 따르기 위해 노력했지만 언어가 다르기 때문에 약간의 편차가 불가피했습니다. 예를 들어 Marlowe 구현의 일부 측면은 Isabelle에서 비효율적이므로 보다 효율적인 Haskell 구현을 위해 변경이 필요했습니다.
내부 대응
이 문제는 코드 분석 및 속성 기반 테스트를 통해 완화되었습니다.
돈 보존 정리 증명
화폐 보존 정리는 자산의 양만 고려했지만 유형은 고려하지 않았습니다. 이것은 증명이 예를 들어 계약이 20 ada와 15 Djed를 받고 20 Djed와 15 ada를 상환할 수 있는 경우를 고려하지 않는다는 것을 의미했습니다.
내부 대응
Isabelle 코드의 개정으로 이 문제가 해결되었습니다. 특히, 새로운 MultiAssets 유형 추가 및 Isabelle 코드 리팩터링(인터프리터 수정 없음)은 자산이 보존되었음을 증명합니다.
Marlowe의 기본 제공 보안 강화 기능 제한
Marlowe에는 특정 보안 위험이 발생하지 않도록 하기 위해 몇 가지 제한 사항이 있습니다.
- 계약은 유한합니다
- 계약이 종료됩니다
- 계약에는 명확한 수명이 있습니다.
- 계약이 종료되면 자산이 유지되지 않습니다.
- 가치가 보존됩니다
이러한 제한 외에도 안전을 보장하기 위해 Marlowe에는 일부 프로그래밍 언어 구성이 없습니다.
- 재귀는 허용되지 않습니다
- 루핑은 지원되지 않습니다
- 함수 또는 매크로를 정의할 수 없습니다.
- 제한 시간은 숫자 상수여야 합니다.
- Case 연속물만 머클화할 수 있습니다. Faustus 프로그래밍 언어는 위의 제한 사항 중 일부를 완화하지만 Marlowe를 보호하기 위해 컴파일됩니다.
보안 분석 도구
Marlowe 팀이 설계한 marlowe-cli 실행 분석 분석 도구는 Marlowe 계약과 Cardano 원장 규칙의 호환성을 확인합니다.
Cardano 원장은 계약 자체가 Marlowe 언어와 관련하여 유효하더라도 Marlowe 계약이 온체인에서 실행되는 것을 방지할 수 있는 제한 사항이 내장되어 있습니다. 예를 들어 원장은 역할 및 토큰 이름의 길이에 제한을 가하고 Plutus 실행 비용도 제한합니다. 이러한 규칙을 위반하는 모든 계약은 계약이 올바르게 구성되더라도 온체인에서 실행되지 않습니다. 마찬가지로 계약이 Playground에서 실행될 수 있지만 계약이 원장 제한을 위반하는 경우 온체인에서 실행되지 않습니다. 기본 제공 원장 디자인 제한 사항에 대해 자세히 알아보세요.
주요 내용: Playground는 언어에 관한 것이지만 Runtime은 특히 Cardano 블록체인에서 Marlowe 계약을 구현하는 것에 관한 것입니다. 누군가 다른 블록체인에서 Marlowe를 구현하는 경우 Playground를 계속 사용할 수 있지만 다른 블록체인에서 Runtime을 사용할 수는 없습니다.
참고: 데이터가 온체인에 맞지 않으면 계약이 잠길 수 있지만 Marlowe 제품군에는 이 위험을 평가하는 도구가 포함되어 있습니다. 이러한 도구는 계약을 배포하기 전에 사용해야 합니다.
거래 검증
두 가지 유형의 Plutus 유효성 검사기 스크립트가 UTXO 지출 유효성 검사와 관련됩니다.
- 시맨틱 유효성 검사기
- 지불 검사기
보안 관행에 따르면 트랜잭션의 내용과 함의가 검토되고 잘 이해되지 않는 한 트랜잭션에 서명해서는 안 됩니다. Marlowe 환경에서 이는 Marlowe 계약, 입력 및 상태를 확인하는 것을 의미합니다. 또한 역할 생성 정책(있는 경우)과 사용된 Marlowe 유효성 검사기가 올바른 것인지 확인하는 것을 의미합니다.
아래의 보안 고려 사항은 두 유효성 검사기 스크립트 유형에 모두 적용됩니다.
시맨틱 유효성 검사기
Marlowe 트랜잭션에 서명하기 전에 다음 개념을 잘 이해해야 합니다.
- 거래가 Marlowe 계약을 운영합니까?
- 역할 생성 정책은 무엇입니까(있는 경우)?
- 역할 토큰은 어떻게 배포되었습니까(있는 경우)?
- 현재 계약과 상태는 무엇입니까?
- 계약에 어떤 입력이 적용됩니까?
- 거래에서 또 어떤 일이 일어나고 있습니까?
거래가 Marlowe 계약을 운영합니까?
Plutus 유효성 검사기 스크립트는 지정된 버전의 모든 Marlowe 계약에 대한 범용 해석기입니다. 즉, Marlowe 계약의 UTXO가 스크립트 해시에 있음을 의미합니다. 지불 부분으로 Marlowe 스크립트 해시가 있는 주소에서 트랜잭션 지출을 확인하면 실제 Marlowe 유효성 검사기가 해당 특정 UTXO의 지출을 확인하기 위해 실행될 것임을 확인합니다. 이 저장소의 Marlowe 스크립트 소스 코드를 신뢰할 수 있다고 가정하면 유효성 검사기를 컴파일하고 해시를 계산하여 첫 번째 원칙에서 Marlowe 유효성 검사기의 스크립트 해시를 계산할 수 있습니다.
역할 생성 정책은 무엇입니까(있는 경우)?
발행 정책은 해당 발행 정책의 해시로 식별되는 주어진 토큰 유형의 토큰 작성을 위한 규칙 세트입니다. 이를 발행 정책 ID라고 합니다. 발행 정책은 새 토큰을 생성할 수 있는지 또는 생성된 토큰이 모두 있는지 여부를 결정합니다.
예를 들어, 대출 기관 및 대출 기관과 같은 Marlowe 계약 당사자는 두 가지 방식으로 나타낼 수 있습니다.
주소로: 주소 유형의 각 당사자는 당사자 중 한 사람의 지갑이 보유하고 있는 공개 키와 개인 키 쌍의 인스턴스에 해당합니다. 당사자를 나타내기 위해 주소를 사용하는 것이 역할을 사용하는 것보다 간단하고 저렴합니다. 자신을 인증하기 위해 주소로 대표되는 당사자는 인증을 요구하는 트랜잭션(예: 당사자를 위해 예금 또는 선택을 실행하는 트랜잭션)에 서명하기만 하면 됩니다.
역할 토큰: 유형 역할의 각 당사자는 온체인에 저장된 토큰에 해당합니다. 계약에서 역할 토큰을 인증으로 사용하려면 역할 토큰 발행 정책 ID가 역할 토큰으로 사용하려는 토큰의 발행 정책 ID임을 계약에서 선언해야 합니다. 이 경우, 발행 정책 ID로 식별되는 토큰의 각 자산 이름은 서로 다른 당사자를 나타냅니다. 트랜잭션을 인증하려면 역할 토큰 소유자가 역할 토큰 소유자의 인증이 필요한 트랜잭션의 일부로 트랜잭션을 포함하기만 하면 됩니다. 동일한 자산 이름을 가진 토큰이 두 개 이상 있을 수 있으므로 당사자의 자산 이름이 있는 역할 토큰의 모든 인스턴스를 소유하지 않는 한 기술적으로 역할 당사자를 소유하지 않습니다.
역할 토큰은 어떻게 배포되었습니까?
계약이 당사자를 대표하는 주소만 사용하는 경우 역할에 대한 생성 정책은 문제가 되지 않습니다. 주소의 단점은 증명할 수 있는 전송이 불가능하다는 점입니다. 따라서 주소에 대한 개인 키가 알려지면 이를 잊고 삭제했음을 보여줄 수 없습니다. 주소 수신자의 관점에서 주소는 항상 안전하지 않습니다. 안전한 주소를 갖는 유일한 방법은 직접 생성하는 것입니다.
이점 또는 역할은 토큰이 체인에서 기본 자산으로 취급되기 때문에 ADA 또는 다른 자산처럼 전송할 수 있다는 것입니다. 그러나 올바른 발행 정책 ID와 자산 이름을 가진 토큰을 소유한 사람은 토큰이 대표하는 당사자 역할을 할 수 있으므로 그러한 토큰을 소유한 유일한 사람인지 확인해야 합니다. 파티.
물론 역할 토큰을 직접 생성하여 해당 토큰을 소유한 유일한 사람임을 확인할 수 있습니다(Marlowe Runtime은 계약 생성 프로세스의 일부로 이를 안전하게 수행합니다). 다른 사람이 역할 토큰을 발행했거나 계약을 생성한 경우 다음을 확인해야 합니다.
파티를 제어하는 기존 토큰이 모두 있습니다.
더 이상 이러한 토큰을 만들 수 없습니다(조폐 정책에서 허용하지 않기 때문).
발행 정책이 충분히 간단한 경우 이를 확인하는 가장 쉬운 방법은 Marlowe 스캐너를 사용하여 계약의 역할 발행 정책 ID를 찾는 것입니다. 그런 다음 Cardano 탐색기를 사용하여 발행 정책 뒤에 있는 정책이 무엇인지 확인하고(더 이상 역할이 생성되지 않도록 하기 위해) 이미 발행된 기존 역할의 현재 분포(누가 어떤 토큰을 가지고 있는지)를 확인합니다.
현재 계약과 상태는 무엇입니까?
계약의 거래 전 상태는 Marlowe 스크립트 주소에서 소비되는 UTXO와 관련된 Plutus 데이터에서 정의됩니다. 이 데이터는 트랜잭션에서 제공되어야 하며 다음을 포함해야 합니다.
계약 내부 계정의 잔액
계약 실행에서 이 시점까지 이루어진 선택의 역사
컨트랙트 바인딩 변수의 현재 값
실행해야 할 계약의 일부
서명되지 않은 트랜잭션 본문에서 데이터를 추출하고 Plutus.V2.Ledger.Api.fromData 함수를 사용하여 Language.Marlowe.Core.V1.Semantics.MarloweData로 역직렬화할 수 있습니다.
대안:
- 명령줄 도구 marlowe log --show 계약은 계약의 온체인 기록을 표시합니다.
- 이 온라인 도구를 사용하면 계약 및 상태 온체인을 볼 수도 있습니다.
- REST API는 marlowe log --show를 통해 얻은 것과 동일한 정보를 제공합니다.
계약에 어떤 입력이 적용됩니까?
Marlowe 스크립트 주소에서 UTXO를 사용하는 것과 관련된 Plutus 구속자는 트랜잭션 본문에 지정된 트랜잭션에 대한 슬롯 유효 간격과 함께 계약에 적용되는 입력을 정의합니다. 입력은 0개 이상의 입금, 선택 및 알림의 시퀀스입니다. Marlowe Playground 또는 marlowe-cli run prepare와 같은 도구를 사용하여 이 입력을 계약에 적용한 결과를 분석할 수 있습니다.
구속자는 서명되지 않은 트랜잭션 본문에서 추출하고 Plutus.V2.Ledger.Api.fromData 함수를 사용하여 Language.Marlowe.Scripts.MarloweInput으로 역직렬화할 수 있습니다. 명령줄 도구 marlowe-cli util slotting은 계약의 POSIX 시간에 대한 유효성 간격에 언급된 슬롯 간의 관계를 계산합니다.
거래에서 또 어떤 일이 일어나고 있습니까?
서명되지 않은 거래에는 Marlowe 계약에 지정된 것 이외의 다른 지출 및 지불이 포함될 수 있습니다. 이는 cardano-cli 트랜잭션 보기 도구로 검사할 수 있습니다.
통화 정책
일반적으로 각 역할에 대해 단일 발행 이벤트 및 단일 토큰을 시행하는 통화 정책(Marlowe Runtime에서 지원되는 것과 같은)을 사용해야 합니다. 이러한 정책은 역할 토큰이 진정한 NFT(대체 불가능한 토큰)임을 보장하므로 역할 토큰 보유자는 계약에서 당사자 역할을 할 수 있는 유일한 사람입니다.
특정 역할 토큰의 여러 복사본을 발행하는 통화 정책 또는 개방형 발행 정책이 있는 정책은 비표준 사용 사례를 지원합니다. 예를 들어, 각 역할 토큰의 사본 두 개를 만들어 같은 당사자에게 배포하면 ‘핫’ 역할 토큰이 포함된 지갑에 액세스할 수 없게 될 경우 해당 당사자가 백업으로 하나의 토큰을 콜드 스토리지에 보관할 수 있습니다. 일부 새로운 크라우드소싱 계약에는 많은 참가자에게 역할 할당(계약이 시작된 후에도 생성될 수 있는 동일한 역할 토큰을 통해)이 포함될 수 있습니다. 마지막으로 역할 토큰에 대한 Plutus 계약의 발행 정책은 하나 이상의 Marlowe 계약 운영과 조정할 수 있습니다.
역할 토큰
역할 토큰은 Marlowe 트랜잭션에서 예금 및 선택을 승인할 수 있습니다. 역할 토큰의 사용 권한을 부여하는 것은 공개 키로 권한을 부여하는 것보다 더 유연합니다. 역할 토큰(따라서 Marlowe 계약 참여)이 지갑 간에 또는 다른 사람에게 전송될 수 있기 때문입니다.
Marlowe 유효성 검사기 스크립트는 새로운 사용 사례를 지원하기 위해 역할 토큰에 대한 특정 통화 정책을 시행하지 않습니다. 그러나 역할 기반 Marlowe 계약의 권한 부여 보안은 역할 토큰 통화 정책에 크게 의존합니다. 이는 Marlowe 계약에 참여하기 전에 통화 정책과 토큰의 온체인 지급을 면밀히 조사해야 함을 의미합니다. 간단한 스크립트의 통화 정책을 확인하려면 블록체인에서 스크립트를 검색하고 연구해야 합니다. Plutus 스크립트의 통화 정책을 확인하려면 해당 스크립트의 Plutus 소스 코드를 획득 및 연구하고 소스 코드를 해싱하여 통화 정책 ID를 확인합니다.
감사의 말: Joseph Fajen, Brian Bush, Omer Husain은 모두 이 기사에 귀중한 기여를 했습니다.