Bài giảng 3: Vesting và Cardano Testnet
Plutus Pioneer Program - Cohort 3 January 26, 2022
Offical Video by Lars Brünjes: PPP-Cohort3-Lecture3
Google Doc version can be found HERE
Video thực hành Deploy smartcontract Vesting trên testnet Preprod.
#
Table of Contents#
Preparation for Lecture 3Trước khi chúng ta có thể bắt đầu trong Bài giảng 3, trước tiên chúng ta phải cập nhật môi trường phát triển của mình. Bạn có thể sao chép và dán trực tiếp bất kỳ mã nào trong hướng dẫn này vào Terminal hoặc IDE của mình.
Đầu tiên, hãy vào thư mục plutus-pioneer-program để lấy nội dung bài giảng tuần 3. Hành hình:
Bây giờ bạn có thể điều hướng đến thư mục week03 hiện tại và mở tệp cabal.project:
Lấy thẻ plutus-apps bên trong tệp cabal.project:
Quay trở lại thư mục plutus-apps và cập nhật nó vào thẻ git hiện tại:
Bây giờ bạn đã được cập nhật và có thể chạy nix-shell trong thư mục này. Chạy nix-shell:
Quay trở lại thư mục week03 để bắt đầu chạy các lệnh cabal:
Nếu thành công, bây giờ bạn sẽ thấy trong Terminal :
Bài giảng này cũng sẽ khám phá Cardano Testnet Preprod. Để tương tác với nó sau này, trước tiên chúng ta cần đồng bộ hóa nút cục bộ, có thể mất hơn 1 giờ. Hãy bắt đầu trong nền:
Giữ cabal mở trên Terminal 1 và mở Terminal mới 2. Đi tới thư mục ứng dụng plutus và chạy nix-shell trước:
Chúng ta có thể kiểm tra phiên bản của Cardano Node và bằng các lệnh:
Nếu chưa có cardano-node và cardano-cli chúng ta có thể download file binary của iohk về máy
sau đó kiểm tra lại bước trên
Tiếp đến chúng ta chạy node trên testnet preprod
tạo cấu trúc thư mục cntool
Cập nhật PATH
sau đó vào thư mục để chạy node
kết quả như thế này và để nguyên Terminal đó để đồng bộ
Quá trình này sẽ mất 1 giờ or hơn để đồng bộ hóa. Bạn sẽ được đồng bộ hóa 100% sau khi bạn bắt đầu thấy một khối mới cứ sau 20 giây, thay vì nhiều khối mỗi giây. Để thiết bị đầu cuối này mở và bây giờ chúng ta có thể bắt đầu.
#
Plutus Playground TimeoutNếu máy chủ sân chơi plutus gặp thời gian chờ trước khi hoàn thành, chúng ta có thể sử dụng lệnh này thay thế để kéo dài thời gian chạy:
#
Script ContextTrong bài giảng này, chúng ta sẽ khám phá script context
. Nếu chúng ta còn nhớ bài giảng 2, script context
là phần thứ ba của dữ liệu trên chuỗi xác định mục đích cho việc chạy:
Nếu xem tài liệu về cardano, chúng ta có thể thấy một ví dụ đơn giản:
Ví dụ trực quan: một đứa trẻ muốn đi đu quay, nhưng trước khi lên, chúng phải cao hơn biển báo an toàn. Chúng ta có thể diễn đạt ý tưởng đó bằng mã giả, như:
Trong ví dụ này, những điều sau đây được áp dụng:
- The datum à thông tin về giao dịch này:
michael.height
. - The context là trạng thái của thế giới, tại thời điểm đó có nghĩa là:
ferrisWheel.minimumHeight
. - Reedemer, là hành động để thực hiện:
getOnFerrisWheel()
- The validator script Tập lệnh trình xác thực là chức năng sử dụng tất cả thông tin đó
isTallEnough
#
Handling TimeTrong mô hình Cardano eUTxO, giao dịch vẫn có thể thất bại. Điều này là do một giao dịch có thể tiêu thụ một đầu vào, khi giao dịch đó đến trên chuỗi khối tại nút để xác thực, nó có thể đã được một người khác sử dụng. Nhưng trong trường hợp đó, giao dịch đơn giản là thất bại mà không phải trả phí. Nhưng điều không bao giờ có thể xảy ra hoặc sẽ không bao giờ xảy ra trong các trường hợp bình thường, đó là tập lệnh xác thực chạy và sau đó không thành công. Lỗi sẽ xảy ra trước khi nó được gửi. Đó là một tính năng tuyệt vời, tuy nhiên nó có nhiều ẩn ý về cách thể hiện thời gian.
Chúng tôi muốn có thể thể hiện logic xác thực nói rằng một giao dịch nhất định chỉ hợp lệ sau khi đạt đến một thời gian nhất định hoặc trước khi đạt đến một thời điểm nhất định. Chúng ta đã thấy một ví dụ về điều đó trong ví dụ đầu tiên, ví dụ đấu giá, giá thầu chỉ được phép cho đến khi đạt đến thời hạn. Điểm cuối gần chỉ có thể được gọi sau khi thời hạn đã qua.
Nếu bạn nghĩ về điều đó, thì đó dường như là một mâu thuẫn bởi vì thời gian rõ ràng là đang trôi. Khi bạn cố gắng xác thực một giao dịch mà bạn đang xây dựng trong ví của mình, tất nhiên, thời gian xảy ra trong ví có thể khác với thời gian giao dịch đến một nút để xác thực. Không rõ làm thế nào để kết hợp hai thứ này lại với nhau để một mặt xử lý thời gian, nhưng mặt khác đảm bảo rằng việc xác thực là xác định theo nghĩa là nếu nó thành công trong ví thì nó cũng sẽ thành công trong nút.
Cardano giải quyết vấn đề này bằng cách thêm trường phạm vi thời gian POSIX này và trường phạm vi hợp lệ của thông tin TX vào một giao dịch. Với điều này, chúng ta có thể tuyên bố một giao dịch là hợp lệ trong khoảng thời gian xác định được chỉ định trong giao dịch. Khi một nút đang xác thực một giao dịch, một trong những bước kiểm tra trước này trước khi xác thực, là nút sẽ kiểm tra thời gian hiện tại và so sánh nó với phạm vi thời gian được chỉ định trong giao dịch. Nếu thời gian hiện tại không nằm trong phạm vi thời gian này, thì quá trình xác thực không thành công ngay lập tức mà không bao giờ chạy tập lệnh trình xác thực. Điều đó cũng có nghĩa là nếu những lần kiểm tra trước này thành công, thì chúng ta có thể giả định rằng thời gian hiện tại rơi vào khoảng thời gian này. Điều này bảo tồn các thuộc tính eUTxO xác định.
Theo mặc định, tất cả các giao dịch sử dụng phạm vi thời gian vô hạn. Điều này bắt đầu từ đầu thời gian hoặc tại khối Genesis và kéo dài vĩnh viễn. Các giao dịch này sẽ luôn hợp lệ, bất kể thời gian chúng đến một nút để xác thực. Các trường hợp ngoại lệ duy nhất mà chúng ta đã thấy cho đến nay là những trường hợp trong ví dụ đấu giá, trong đó giá thầu và giá đóng không thể sử dụng khoảng thời gian vô hạn vì chúng ta đảm bảo rằng giá thầu diễn ra trước thời hạn và giá đóng sau thời hạn. Tuy nhiên, theo mặc định, tất cả các giao dịch bao gồm các giao dịch mà bạn gửi từ Daedalus chẳng hạn, sẽ luôn sử dụng phạm vi thời gian vô hạn.
Có một sự phức tạp nhỏ là Ouroboros, giao thức đồng thuận cung cấp năng lượng cho Cardano, không sử dụng thời gian POSIX; nó sử dụng khe cắm. Plutus sử dụng thời gian thực, vì vậy chúng ta cần có khả năng chuyển đổi qua lại giữa thời gian thực và thời gian. Ngay bây giờ, độ dài khe là một giây. Biết rằng, thật dễ dàng để chuyển đổi qua lại giữa thời gian thực và số vị trí. Tuy nhiên, điều này có thể thay đổi trong tương lai thông qua thay đổi tham số thông qua một hard fork. Và, tất nhiên, chúng ta không thể biết trước điều đó.
Chẳng hạn, hiện tại chúng ta không biết độ dài của vị trí sẽ là bao nhiêu trong 10 năm nữa. Điều này có nghĩa là chúng ta không được có giới hạn trên nhất định. Chúng tôi biết thời lượng của vị trí sẽ là bao nhiêu trong 36 giờ tới vì nếu có thay đổi về tham số giao thức, thì chúng ta sẽ biết điều đó trước ít nhất 36 giờ. Bạn không thể chỉ định phạm vi thời gian tùy ý trong khoảng thời gian giao dịch. Nó chỉ được tối đa là 36 giờ trong tương lai hoặc có thể là vô thời hạn.
Vì vậy, hãy xem loại phạm vi thời gian POSIX này.
Trong đó Khoảng thời gian là:
Trong đó Giới hạn dưới là:
Trường hợp đóng Closure
là:
Trường hợp mở rộng là:
Một số chức năng hữu ích để xác định giới hạn:
Bây giờ chúng ta có thể thực hành một số thay thế cabal. Đầu tiên chúng ta sẽ nhập Plutus.V1.Ledger.Interval.
Ví dụ khoảng thời gian :
Ví dụ Thành viên:
Ví dụ bắt đầu từ:
Ví dụ đến:
Example Intersection:
Ví dụ trong khoảng:
Ví dụ Overlaps:
#
Vesting ContractBây giờ chúng ta sẽ xem xét một ví dụ về hợp đồng trao quyền Vesting Contract
. Hãy tưởng tượng bạn muốn tặng một món quà ADA cho một đứa trẻ. Bạn muốn đứa trẻ sở hữu ADA, tuy nhiên, bạn chỉ muốn đứa trẻ có quyền truy cập vào ADA khi chúng đến một độ tuổi cụ thể. Sử dụng plutus, rất dễ dàng thực hiện một kế hoạch trao quyền thỏa mãn các điều kiện đó.
Trước tiên, chúng ta xem xét mốc thời gian được thông qua với hai mẩu thông tin; Người thụ hưởng và thời hạn:
Sau đó, chúng ta xem xét chức năng trình xác thực:
Chúng tôi đã xác định mốc thời gian là dat và context là ctx. Sau đó, chúng ta kiểm tra đúng người thụ hưởng bằng cách tạo hàm SignByBeneficiary và thời hạn bằng hàm deadlineReached.
Sau đó mã hóa mốc thời gian và redeemer:
Bây giờ chúng ta cần xử lý việc biên dịch:
Tiếp theo là mã soạn sẵn cho trình xác thực, hàm băm và địa chỉ:
Cuối cùng, mã ngoài chuỗi off-chain
:
Bây giờ chúng ta có thể kiểm tra điều này trong Plutus Playground.
Để bắt đầu với Plutus Playground, chúng ta cần có hai Terminal đang chạy, cả hai đều nằm trong nix-shell.
Hãy bắt đầu với terminal 1. Đi tới thư mục plutus-apps và chạy nix-shell trước:
Tiếp theo, chúng ta đi đến thư mục plutus-playground-server và chạy:
Nếu thành công, bạn sẽ thấy đầu ra:
Hãy bắt đầu với terminal 2. Đi tới thư mục plutus-apps và chạy nix-shell trước:
Tiếp theo, chúng ta đi đến thư mục plutus-playground-client và chạy:
Nếu thành công, bạn sẽ thấy đầu ra:
Giữ cả hai Terminal mở và giờ đây chúng ta có thể truy cập Plutus Playground từ trình duyệt.
Mở trình duyệt và truy cập địa chỉ:
Bạn sẽ nhận được một cảnh báo phàn nàn về việc đây là một trang web nguy hiểm, dù sao hãy bỏ qua thông báo để nhấp qua. Giờ đây, bạn có thể biên dịch và chạy thành công hợp đồng quà tặng bằng cách sao chép/dán nó vào Plutus Playground và sử dụng hai nút ở góc trên cùng bên phải: “Biên dịch” và “Mô phỏng”.
Trước khi chúng ta thực hiện mô phỏng của mình, chúng ta cần tìm mã hash của ví thanh toán pubkeyhash
cho ví 2 và 3. Chúng tôi có thể thực hiện việc này:
Chúng tôi có thể sao chép/dán các giá trị băm đó vào simulation cho ví 2 và 3.
Chúng tôi cũng cần chuyển đổi các vị trí thành POSIXTime, điều mà chúng ta cũng có thể thực hiện trong Terminal này:
Các ví sẽ trông giống như:
Khe Genesis 0 trông giống như:
Khe 1, TX 0:
Khe 2, TX 0:
Khe 3, TX 0:
Slot 12, TX 0:
Slot 12, TX 1:
Số dư cuối kỳ:
#
Parameterized ContractBây giờ chúng ta sẽ xem xét một ví dụ tương tự về hợp đồng trao quyền, ngoại trừ việc chúng ta sẽ chuyển một tham số thay vì một mốc thời gian. Trước tiên chúng ta có thể xem mkValidator, trong đó datum hiện là kiểu unit():
Sau đó mã hóa datum tới kiểu unit:
Sửa đổi phần compiler:
Tiếp theo là mã cho trình xác thực, hàm băm và địa chỉ:
Tiếp theo là mã ngoài chuỗi:
Bây giờ chúng ta có thể kiểm tra điều này trong Plutus Playground.
Nhìn vào thiết lập ví:
Khe Genesis 0 trông giống như:
Slot 1, TX 0:
Slot 3, TX 0:
Slot 12, TX 0:
Slot 12, TX 1:
Số dư cuối kỳ:
#
Cardano Testnet Smartconctact trên mạng PreprodMạng thử nghiệm Cardano preprod
Bây giờ chúng ta sẽ xem xét Cardano CLI và cách nó tương tác với testnet. Hy vọng rằng tại thời điểm này, nút cục bộ của bạn hiện đã được đồng bộ hóa từ công việc được thực hiện trong phần “chuẩn bị cho bài giảng 3”.
Giao diện dòng lệnh (CLI) cung cấp một tập hợp các công cụ để tạo khóa, xây dựng giao dịch, tạo chứng chỉ và thực hiện các tác vụ quan trọng khác. Nó được tổ chức theo một hệ thống phân cấp các lệnh con và mỗi cấp độ đi kèm với tài liệu tích hợp sẵn về cú pháp lệnh và các tùy chọn.
Phần này cung cấp tài liệu tham khảo về các lệnh cốt lõi cardano-cli
và các lệnh con liên quan của chúng:
cardano-cli
cardano-cli
The set of cardano-cli
commands include:
address
: payment address commandsstake-address
: stake address commandstransaction
: transaction commandsnode
: node operation commandsstake-pool
: stake pool commandsquery
: node query commands. Commands in this group query the local node whose Unix domain socket is obtained from the CARDANO_NODE_SOCKET_PATH environment variable.genesis
: genesis block commandstext-view
: commands for dealing with text view files that are stored on disk, such as transactions or addressesgovernance
: governance commands
cardano-cli address
The address
command contains the following subcommands:
key-gen
: creates a single address key pairkey-hash
: prints the hash of an address to stdoutbuild
: builds a payment address, with optional delegation to a stake addressbuild-script
: builds a token locking scriptinfo
: prints details about the address
cardano-cli stake-address
The stake-address
command contains the following subcommands:
key-gen
: creates a single address key pairbuild
: builds a stake addresskey-hash
: prints the hash of a stake verification keyregistration-certificate
: creates a registration certificatedelegation-certificate
: creates a stake address delegation certificatederegistration-certificate
: creates a de-registration certificate
cardano-cli transaction
The transaction
command contains the following subcommands:
build-raw
: builds a low-level transaction (uses the--cardano-mode
,--byron-mode
,--shelley-mode
flags)build
: builds an automatically balanced transaction (automatically calculates fees)sign
: signs the transactionassemble
: combines and assembles the transaction witness(es) with a transaction body to create a transactionwitness
: witnesses a transactionsubmit
: submits the transaction to the local node whose Unix domain socket is obtained from the CARANO_NODE_SOCKET_PATH environment variable (uses the--cardano-mode
,--byron-mode
,--shelley-mode
flags)calculate-min-fee
: calculates the minimum fee for the transactioncalculate-min-required-utxo
: calculates the minimum required ADA for a transaction outputhash-script-data
: calculates the hash of script data (datums)txid
: retrieves the transaction IDpolicyid
: retrieves the policy IDview
: pretty prints a transaction
cardano-cli node
The node
command contains the following subcommands:
key-gen
: creates a key pair for a node operator's offline key and a new certificate issue counterkey-gen-KES
: creates a key pair for a node KES operational keykey-gen-VRF
: creates a key pair for a node VRF operational keykey-hash-VRF
: creates a key hash for a node VRF operational keynew-counter
: keeps track of the number of KES evolutions for a given operational certificate hot keyissue-op-cert
: issues a node operational certificate
cardano-cli stake-pool
The stake-pool
command contains the following subcommands:
registration-certificate
: creates a stake pool registration certificatede-registration-certificate
: creates a stake pool de-registration certificateid
: builds pool id from the offline keymetadata-hash
: retrieves the metadata hash
cardano-cli query
The query
command contains the following subcommands:
protocol-parameters
(advanced): retrieves the node's current pool parameters (a raw dump ofLedger.ChainDepState
).tip
: gets the node's current tip (slot number, hash, and block number)stake-pools
: gets the node's current set of stake pool idsutxo
: retrieves the node's current UTxO, filtered by addressledger-state
(advanced): dumps the current state of the node (a raw dump ofLedger.NewEpochState
)stake-distribution
: gets the node's current set of stake pool idsprotocol-state
(advanced): dumps the node's current protocol statestake-address-info
: gets the current delegations and reward accounts filtered by stake address.stake-distribution
: gets the node's current aggregated stake distributionstake-snapshot
(advanced): gets the stake snapshot information for a stake poolpool-params
(advanced): gets the current and future parameters for a stake poolleadership-schedule
: gets the slots in which the node is slot leader for the current or following epochkes-period-info
(advanced): returns diagnostic information about your operational certificate
cardano-cli governance
The governance
command contains the following subcommands:
create-mir-certificate
: creates an MIR (move instantaneous rewards) certificatecreate-update-proposal
: creates an update proposalcreate-genesis-key-certificate
: retrieves the genesis key certificate
cardano-cli genesis
The genesis
command contains the following subcommands:
key-gen-genesis
: creates a genesis key pairkey-gen-delegate
: creates a genesis delegate key pairkey-gen-utxo
: creates a genesis UTxO key pairkey-hash
: prints the identifier, or hash, of a public keyget-ver-key
: derives verification key from a signing keyinitial-addr
: gets the address for an initial UTxO based on the verification keyinitial-txin
: gets the transaction ID for an initial UTxO based on the verification key.create
: creates a genesis file from a genesis template, as well as genesis keys, delegation keys, and spending keys.create-staked
: creates a staked genesis filehash
: retrieves the hash value
unit cardano-cli text-view
Thetext-view
command contains the following subcommand:decode-cbor
: prints a text view file as decoded CBOR.
Để kiểm tra các hợp đồng của chúng ta, trước tiên chúng ta cần tạo các cặp khóa trên mạng thử nghiệm. Chúng ta có thể bắt đầu bằng cách mở một Terminal mới để chạy nix-shell, đảm bảo không đóng nút đồng bộ hóa trong terminal khác:
Kiểm tra mạng đã đồng bộ xong chưa bằng lệnh
Kết quả sẽ thấy như sau là đã đồng bộ xong và có thể chạy thử nghiệm được.
Chuyển đến thư mục con week03 trong thư mục tiên phong plutus, sau đó bên trong thư mục testnet. Trước tiên, chúng ta sẽ tạo khóa công khai và khóa riêng 01.vkey và 01.skey tương ứng bằng lệnh:
Bây giờ chúng ta sẽ tạo khóa công khai và khóa riêng thứ hai lần lượt là 02.vkey và 02.skey bằng lện
Nhìn vào 01.vkey:
Bây giờ chúng ta có thể tạo địa chỉ trên testnet cho 01.vkey và xuất địa chỉ đó vào tệp 01.addr bằng lệnh sau:
Nhìn vào 01.addr:
Bây giờ chúng ta có thể tạo địa chỉ trên testnet cho 02.vkey và xuất địa chỉ đó vào tệp 02.addr bằng lệnh sau:
Nhìn vào 02.addr:
Bây giờ chúng ta cần tạo một số ADA để gửi đến địa chỉ đầu tiên của chúng ta. Điều này có thể được thực hiện từ trang sau bằng cách sử dụng faucet Cardano.
Điều quan trọng cần lưu ý ở đây là địa chỉ của bạn cho 01.addr sẽ khác với địa chỉ được tạo trong hướng dẫn này! Đảm bảo bạn gửi ADA testnet đến địa chỉ bạn đã tạo trong CLI!
Bây giờ chúng ta sẽ có thể truy vấn địa chỉ. Điều quan trọng cần lưu ý ở đây, nút cục bộ của bạn phải được đồng bộ hóa với chuỗi khối vào thời điểm này, nếu không bạn sẽ không thể thấy tiền!
Bây giờ chúng ta sẽ gửi một số tiền đến địa chỉ thứ hai của mình bằng cách sử dụng tập lệnh được tạo sẵn send.sh:
Lưu ý quan trọng, bạn cần thay đổi tx-in
thành hàm băm TxHash
của 01.addr nơi chúng ta đã gửi tiền ở bước trước! Cũng lưu ý rằng nó kết thúc bằng #0 chỉ định chỉ số TxIx
giao dịch ở đây là 0
và chạy:
Sau khi đợi khoảng 20 giây, chúng ta có thể truy vấn địa chỉ đầu tiên để xem tiền đã được gửi chưa:
Để bắt đầu sử dụng Plutus bằng Cardano-CLI, chúng ta cần tuần tự hóa và ghi vào đĩa các loại Plutus khác nhau. Tuy nhiên, trước tiên chúng ta cần lấy PaymentPubKeyHash
của ví 2:
tạo biến
Nhìn vào Deploy.hs, chúng ta cần thay thế hàm băm khóa công khai thanh toán của người thụ hưởng bằng hàm băm mà chúng ta đã tạo ở trên. Lưu ý rằng hàm băm của bạn sẽ khác với hàm băm trong hướng dẫn này. Chúng tôi cũng thay thế thời hạn bằng một thời gian trong tương lai. (bạn có thể sử dụng Epoch Converter để tìm dấu thời gian trong tương lai)
#
Biên dịch smartcontract plutusMở cabal repl trong Terminal khác và chạy:
#
Tạo giao dịch với SmartContract#
B1 Tạo địa chỉ ví smartcontract#
B2: Lấy Txin của địa chỉ gửitạo biến
#
B3: tạo giao dịch gửi tADA lên SmartcontractNhìn vào tập lệnh give.sh, chúng ta thay đổi tx-in
thành địa chỉ query 1 utxo mà chúng ta đã tạo trước đó:
Bây giờ chúng ta có thể xem tập lệnh grab.sh. Chúng ta sẽ thay đổi hàm băm Txin
thành hàm băm của vesting.addr mà chúng ta đã gửi lên. Chúng tôi sẽ thay đổi tài sản thế chấp thành hàm băm của 02.addr từ trước đó. Chúng tôi cũng sẽ thay đổi hàm băm của người ký thành hàm băm của 02.pkh. Cuối cùng, chúng ta cần thay đổi invalid-before
để phản ánh vị trí hiện tại; mà chúng ta đã truy vấn ở bước cuối cùng:
#
B4: Lấy Txin của địa chỉ Smartcontract vừa gửi lên#
B5: Lấy slot hiện tại#
B6: tải protocol.json#
B7: Lấy Txin của địa chỉ nhận (trả phí)#
B8: Ví người thụ hưởng nhận quà (tADA)thay đổi các thông số --tx-in; tx-in-collateral; --invalid-before; --required-signer-hash (vẫn hợp đồng cũ thì không đổi)
Nếu sai thì sẽ báo lỗi sau
Nếu không
Sau khi đợi khoảng 20 giây, chúng ta có thể truy vấn địa chỉ thứ hai để xem cuối cùng đã nhận được tiền từ món quà chưa:
Địa chỉ Smartcontract đã không còn UTxO
#
Homework Part 1- Điều này sẽ hợp lệ nếu một trong hai người thụ hưởng1 đã ký giao dịch và vị trí hiện tại là trước hoặc vào thời hạn
- Hoặc nếu người thụ hưởng2 đã ký giao dịch và thời hạn đã qua.
Phần đầu tiên của bài tập về nhà, chúng ta cần viết một hàm trình xác thực sẽ trả về giá trị true nếu người thụ hưởng1 đã ký giao dịch và vị trí hiện tại là trước hoặc vào thời hạn chót. Nó cũng phải trả về true nếu người thụ hưởng2 đã ký giao dịch và thời hạn đã qua.
Trước tiên chúng ta cần chuyển datum (dat) và context (ctx) vào trình xác thực:
Sau đó, chúng ta cần viết logic thỏa mãn cả hai điều kiện đã được mô tả ở trên:
Chúng tôi kiểm tra cả hai điều kiện, một điều kiện mà người thụ hưởng1 ký và nó ở trước hoặc vào thời hạn, và cũng là trường hợp người thụ hưởng2 ký và nó ở sau thời hạn. Nếu không, tất cả những thứ khác trả về false. Mã sẽ giống như:
Thử nghiệm trong Plutus Playground ta thấy:
Slot 0, Tx 0
Slot 1, Tx 0
Slot 1, Tx 1
Slot 6, Tx 0
Slot 7, Tx 0
Số dư cuối kỳ:
#
Homework Part 2Phần thứ hai của bài tập về nhà, chúng ta cần viết hàm trình xác thực cho hợp đồng trao quyền, thay vào đó chúng ta chuyển pubkeyhash làm tham số và POSIXTime như là datum.
Chúng tôi có thể bắt đầu bằng cách kiểm tra xem chữ ký của người thụ hưởng có tồn tại hay không và thời hạn đã đến chưa. Đầu tiên chúng ta vượt qua:
Bây giờ chúng ta lấy logic như được mô tả ở trên:
Implementing the compilation: Thực hiện biên soạn:
Cuối cùng là mã cho trình xác thực và địa chỉ. Ở đây chúng ta cần thêm PaymentPubKeyHash:
Mã cuối sẽ giống như này:
Mô phỏng Plutus Playground sẽ giống như sau:
Slot 0, Tx 0
Slot 1, Tx 0
Slot 2, Tx 0
Slot 12, Tx 0
Slot 22, Tx 0
Số dư cuối kỳ: