SuperNodes have three core states. These states come with implications for the state of rewards from their stakes. Stakers must be aware of these states to fully grasp and inform their staking decisions responsibly. SuperNode state is eligible for transition on every end-block.

Enabled

After self-staking 5,000,000.00 PSL, SuperNode owners are able to activate the signer in order to synchronize to the network, connect with other nodes, and join the active-set. They can sign blocks and earn rewards after an end-block transition to enabled.

SuperNodes in the enabled state are in the active-set and will earn rewards and returns on their staked PSL so long as they remain enabled. Moving self-staked collateral will result in the SuperNode being removed from the active-set.

Disabled

Validators who are in a disabled state are not in the active-set, either by choice or as a result of a misconfiguration or becoming banned (punishment for behavior harmful to network integrity). They cannot sign blocks and they do not earn rewards.

Self-staked collateral held by disabled operators is not locked by the network and is free to move.

Pre-Enabled

Pre-Enabled is a transitory state where a SuperNode is being added to the active-set as the node synchronizes to the network and connects with other peers.

Pastel Network is a fully decentralized, developer-friendly layer-1 blockchain serving as the preeminent protocol standard for non-fungible tokens ("NFTs") and Web3 technology.

Pastel infrastructure enables existing layer-1 blockchains, decentralized applications, or third-party enterprises to protect creators and collectors. From digital collectibles & media to documents & applications, users and developers are able to certify asset rareness and truly store data forever. Lightweight protocols delivered by interoperable open APIs such as Sense and Cascade can be easily integrated across existing networks. A wide range of Web3 applications can be built directly on the Pastel Network, enabling developers to enjoy the scalable registration features, storage processes, and security of the broader ecosystem.

Advantages of Pastel

Application Specific Layer-1 Blockchain

Purpose-built to securely handle all mission critical use-cases pertaining to the NFT and Web3 ecosystem.

Entirely Permissionless

An open network of peer-to-peer nodes, available to everyone to participate in the consensus process that the Pastel Network uses to validate transactions and data.

Negligible Fees

Dynamic fee function supports negligible transaction fees for on and off-chain requests, reducing friction from traditional general-purpose layer-1s.

Reliable Storage

Highly redundant, distributed system achieves permanent storage. Pay once, store forever.

Cross-Chain Interoperability

Natively integrate Open-API standards and trustlessly bridge assets cross-chain.

Secure Foundation

Multi-Layer architecture developed to achieve maximum network security.

Build with Pastel

Open-API Protocols

Integrate native protocols like Sense and Cascade into your very own native blockchain or application via lightweight open web APIs.

Agile Smart Ticket Structure

Easily represent NFT data on the blockchain and add custom features or upgrade existing functionality on Pastel using an innovative ticket schema built on intrinsic data integrity.

Pastel Developer Modules

Develop on-chain marketplaces or third-party applications directly on the Pastel Network, supported by a series of protocols, well-documented APIs, and gRPC functionality to help builders get started.

System requirements

Pastel software runs on the following systems:

• Ubuntu 20.04

Prepare system

Install pre-requisite software:

• Linux

  • sudo apt install libgomp1

For Pastel Network, any participant can qualify to become a SuperNode validator by running a full-node and self-staking PSL tokens. SuperNode operators participating in consensus for Pastel earn block rewards and transaction fees.

SuperNodes have two addresses and it is advised to operate each on isolated nodes:

1. owner address: This address is from the SuperNode operator who handles admin-related functionality like activating the signer and taking custody of PSL collateral.

2. signer address: This address belongs to the SuperNode operator who runs the active network node and performs the various SuperNode operations.

Stake

Stake is measured in PSL, the native token of the Pastel Network.

• Exactly 5,000,000.00 PSL held in a single UTXO ("Staked PSL")

• Full nodes with Staked PSL qualify as SuperNodes

• SuperNodes in the state become part of the active-set

UnStake

Staked PSL is never frozen or programmatically locked, allowing SuperNodes to exit the active-set whenever they choose.

• When the SuperNode wants to exit the system and stop validating blocks or performing operations, they can simply call stop

  • This action is immediate as of the method call

  • After this action the SuperNode is considered out of the active-set set of validators

Pastel Network

Pastel defines its own custom Account type that uses Bitcoin's ECDSA secp256k1 curve for keys. This satisfies the EIP84 for full BIP44 paths.

Addresses and Public Keys

There are 5 main types of Addresses/PubKeys available by default on Pastel:

• Addresses and Keys for transparent accounts, which identify users (e.g. the sender of a message). They are derived using the secp256k1 curve.

• Addresses and Keys for shielded accounts, which identify users (e.g. the sender of a message). They are derived using the secp256k1 curve and zero-knowledge proofs to allow transaction data to be encrypted but remain verifiable by network nodes

Address formats for clients

PSLAccounts are represented in format. The Base58 format is the default format for Pastel queries and transactions through CLI and REST clients.

The PSL token (“PSL”) serves as the native, digital cryptographically-secured utility token of the Pastel Network. By running on a specialized, purpose-built blockchain, PSL is the foundation for accessibility. Inherently, PSL empowers the permissionless, borderless economy for NFTs and Web3.

PSL Use-Cases

Network Operations: Generate a PastelID, Mint NFTs, Submit Tickets, and Perform Open-API Requests

Stake: Operate a SuperNode and stake collateral in exchange for providing computational resources, validation, and security services

Governance: Stakeholders are able to initiate and vote on various proposals

Deflationary Mechanism

Upon core network operations, a percentage of each tx-fee is distributed to a cryptophically unspendable address, resulting in a reduction of the overall supply of PSL ("Proof of Burn").

Key network operations resulting in Proof of Burn:

• PastelID Creation

• NFT Registration

• NFT Activation

• NFT Trade

Multi Layer Structure

Pastel Chain

The Pastel Network begins with the Pastel Chain, a layer-1 blockchain that achieves maximum security, reliability, and decentralization. Cryptographic innovations such as zero-knowledge proofs (zk-SNARKs) allow for provably secure transactions that are validated by the network.

To ensure the security of our Network, we inflate the supply of our token to incentivize SuperNodes to stake PSL and miners to participate in the Pastel Network.

Token Information:

Type: Native Token Symbol: PSL Max Supply: 21,000,000,000.00 PSL (fixed) Initial Total Supply at Genesis: 10,762,197,400.00 PSL Decimals: 8

Emission

The current emission (“Emission Schedule”) accounts for the creation of 6,250 PSL every block (“Block Reward”) with a targeted block time of 2.5 Minutes / Block. The Block Reward is halved every 840,000 blocks. The target PSL inflation at genesis is roughly 12% and will decrease over time to under 1%. As the network matures, total supply of PSL may be lower than the initial supply due to our .

The Block Reward is distributed across key stakeholders and network participants. Miners provide invaluable computational power to secure the network through Proof of Work, while SuperNode operators stake collateral (5,000,000.00 PSL) and delegate computation for the function and validation of key network services.

Current Block Reward Distribution:

• SuperNode Operators: 20%

• Miners: 80%

Pastel also encourages participants to vote on the allocation of resources to support the longevity of the network through a mechanism.

Governance is the process by which plans for reform in the Pastel Network are presented and voted on. As a completely decentralized, peer-to-peer blockchain there are no privileged access admin keys. Through the governance process, proposals can be presented to the community. The ratification of new proposals are handled by a voting process via SuperNodes.

Phase 1: Proposals

All on-chain governance actions start as proposals which can be submitted by any enabled SuperNode that has been active on the network for 17,280 blocks (currently approximately 30 days). Such SuperNodes are able to submit a governance-ticket identifying their various proposal to the network on any given blockHeight, which will then become active after 10 block confirmations.

There are several types of proposals that can be submitted, which include but are not limited to the following:

• Block-Reward Governance Payments

• Parameter Change Proposals

• Bridge Relayer and Orchestrator Proposals

• Plain Text Proposals

Phase 2: Voting Period

After the governance-ticket passes the proposal period, the proposal enters a voting period during which SuperNode operators cast their vote. Any SuperNode operators in the active-set at blockHeight=X are considered for voting as governance participants. The Voting Period lasts 4,032 blocks from the time the proposal is confirmed on the network at blockHeight=X+10.

During the voting period, governance participants have 3 voting options:

• Yes

• No

• Abstain

The Abstain option allows voters to signal that they do not intend to vote in favor or against the proposal but accept the result of the vote.

Phase 3: Tallying Period

There are two conditions that have to be satisfied for the voted proposal to be accepted:

1. Quorum — More than 10.0% of the total governance participant SuperNodes, or active-set SuperNodes at blockHeight=X, need to have participated in the vote.

2. Threshold — At least 50% of votes that participated need to have voted in favor of the proposal (a Yes vote).

If both of these requirements are not met by the end of the voting period, the proposal will be rejected.

Phase 4: Implementation Phase

If the proposal is accepted, it enters the implementation stage. For most proposals, the implementation will be immediate and programmatically executed.

SuperNode Operator Selection is the process to randomly select a SuperNode to receive the blockReward, perform network operations, and earn associated transaction fees.

At each current blockHeight=X, SuperNode Operators are selected to receive blockRewards and perform various operations to take place at a future blockHeight=X+N. N is currently set at 10 blocks.

Voter Selection

Upon every block notification at current blockHeight=X, the top-20 ranked SuperNodes in the active-set are selected as Voters. Ranking is achieved by calculating the XOR distance of the hash of each SuperNode's key against the hash of previous blockHeight=X-M. M is currently set at 101 blocks.

Voting

Each Voter then places an individual vote through the following process:

1. Sort the active-set of SuperNodes by the time since last reward payment from oldest to most recent.

2. Select the top 10% of oldest payees from Step 1.

3. Calculate the rank of the top 10% of oldest payees from Step 2. Ranking is achieved by calculating the the XOR distance of the hash of each SuperNode's private key versus the hash of previous

Winning SuperNode

The SuperNode that receives the most votes from is selected as the Winner for blockHeight=X+N where N is currently set at 10 blocks. In the event of a tie or that no SuperNode is selected, the process repeats. At blockHeight=X+N, the Winner is the recipient of the blockReward, responsible for performing all related network functionality, and eligible to receive related .

Verifying SuperNodes

SuperNodes with the second and third most Votes received from the Voting process are also selected to verify all operations performed by the Winning SuperNode at blockHeight=X+N. While they are not eligible to receive any portion of the blockReward, they do receive a portion of the related for performing additional verification and security functions.

SuperNodes are powerful validator servers backed by staked collateral held in PSL.

SuperNodes host full copies of the blockchain and provide a unique second layer of services to the network, processing advanced functionality such as NFT Registration & Activation, OpenAPI Sense & Cascade Requests, and cross-chain bridge relayers & orchestrators.

This interconnected layer provides an additional level of performance, functionality, and security to the broader Pastel ecosystem. Compute intensive operations can be conducted on high-powered nodes, who collectively verify the output and monitor the state of other SuperNodes on the network prior to data or information being submitted on-chain.

SuperNode operators must self-stake collateral denominated in PSL (this takes the form of a single transaction containing precisely 5,000,000 PSL), and in return their operators receive regular payment for the services they provide to the network. These payments to SuperNodes come from the 20% of the mining block reward that is allocated to SuperNode rewards as a whole, and these are evenly split between all valid SuperNodes. This means that the reward to each SuperNode (as measured by daily estimated rewards in PSL as a % of the 5,000,000 PSL of collateral) depend on the total number of SuperNodes-- the more SuperNodes there are enabled on the network, the less each of them receives in rewards.

As highly committed custodians and validators of the Network, SuperNode operators are also given the opportunity to vote on key ecosystem development and growth initiatives playing a fundamental governance role.

Learn more about running a SuperNode .

Installation directories:

• Windows 10

There are three different types of Pastel nodes in Pastel Network.

Core Node

A Core Node is a full node that fully validates transactions and blocks on the Pastel Network. Core Nodes help the network by accepting transactions and blocks from other full nodes, validating those transactions and blocks, and then relaying them to further full nodes.

Core Nodes also support the following functionality:

Pasteld opens a JSON-RPC endpoint for communication. It is highly recommended that users employ software developed by the core team for communication with the blockchain, however that may not be practical if a user is, for example, seeking to develop their own version of the Node layer.

A comprehensive description of the available JSON-RPC endpoint is located here but is also accessible through pastel-cli's help command.

SuperNode operators that are actively staking on the network and members of the active-set are eligible for selection of various rewards including:

• Block Reward - Currently 20% of the Total Block Reward, or 1,250 PSL as of November, 2022 (this will change over time as the total block reward adjusts down after each "halving").

• Transaction Fees - Received for various successful operations performed including NFT Registration, NFT Activation, OpenAPI Actions (e.g., external Sense and Cascade requests)

In order to qualify to receive these fees, SuperNode operators must do the following:

• Self-stake collateral denominated in PSL (5,000,000 PSL per SuperNode);

• Dedicate a separate machine or cloud instance for each SuperNode with adequate memory, disk space, processing speed, and an "always on" static IP address;

• Ensure they are running the latest compatible version of the open-source Pastel software, and properly configure this software so that their SuperNode is considered by the protocol to be in "good standing."

SuperNode Fees are intended to align the incentives of network operators, reward ongoing good behavior, and increase network participation. The current fee structure should further support the long-term objective of a fully-decentralized peer-to-peer network.

Register NFTs

Process

1. Navigate to the "nfts" section of the Swagger API. Find "/nfts/register/upload" and insert your file and give your file a name.

2. Execute the file upload API call and keep track of the image_id that is returned.

3. Navigate to "/nfts/register/" and fill in the request body. Make sure to replace the image_id with the image_id from step 2. Spendable_address is your pastel address with enough PSL to execute the transaction. You should make sure to input a maximum reasonable PSL fee into the request body as well. Royalty is a percentage calculation.

4. Once all the fields are filled out, execute the /nfts/register/ api call and note the task_id that is returned. This time, unlike Sense and Cascade, if your wallet contains enough PSL the requisite amount will be burned for you automatically.

5. Navigate to the /nfts/register/{taskid}/state API call in Swagger and enter the task_id from step 4.

6. Execute the state call, refreshing this over time will allow you to see the state of the Supernodes as they process it. When this yields "Task Completed" your art has been processed by the blockchain and your NFT is ready! If you want, you can search for your NFT (detailed in Search for NFTs section)

7. In case the registration completes (success or failure), you might not get results from /nfts/register/{taskid}/state API call as that is a websocket connection only active till the registration is in process, in that case, you can use /nfts/<<task_id>>/history API call to go through the registration process life-cycle.

Search for NFTs

Process

1. Navigate to the "nfts" section of the Swagger API. Find "/nfts/search" and filter to your heart's content. Supplying your pastelid and passphrase may allow you to see more information about NFTs you have access to. There are a number of filters this API provides that can be learned by looking at Swagger docs.

2. If you know the transaction ID of a specific NFT you are searching for, the "/nfts/{txid}" API call will let you get the NFT associated with that transaction. You will need to fill in the request body with your pastelid and passphrase to authenticate.

Download NFTs

Process

1. Navigate to the "nfts" section of the Swagger API. Find "/nfts/download" and supply the nft's transaction id (txid) and the owner's pastelID. Your NFT will be returned as a base64 encoded archive. You'll also need to set the Authorization key to the passphrase of owner's PastelID.

The web interface is the preferred method for performing WalletNode's functions, however, it is possible to directly access the GRPC communication channels that the web interface abstracts.

RFC

See https://github.com/pastelnetwork/gonode/tree/master/walletnode for the current working implementation of WalletNode and its RPC interface.

The Pastel Daemon (pasteld for short) has three primary responsibilities:

1. Host the Core Node (cNode) functionality operating the blockchain, validating transactions, and communicating with other nodes.

2. Host and operate the blockchain wallet and PastelID functionality.

3. Host a JSON-RPC interface allowing for communication between cNode and the storage layers above it (walletnode and supernode).

PastelD can be run via command line. Instructions for command line implementation can be found on the following page.

RFC

See https://github.com/pastelnetwork/gonode/tree/master/supernode for the current working implementation of SuperNode and its RPC interface.

The Pastel Network uses a multi-layer technology protocol for its consensus mechanism ("Pastel Consensus Protocol"). All network nodes currently use Proof-of-Work (PoW) while SuperNodes currently use a form of Proof-of-Stake (PoS). This allows the nodes of Pastel to agree on the state of all information recorded on the Pastel blockchain securely, while also aligning validators that operate SuperNodes with network incentives to prevent certain economic attacks.

Proof-of-Work and Mining

Proof-of-work is the mechanism that allows the decentralized Pastel network to come to consensus, such as agreeing on certain things like account balances and the order of transactions. This ensures that users are unable to "double spend" their coins and also means that the Pastel chain is tremendously difficult to attack or manipulate.

PoW is the underlying algorithm that sets the difficulty and rules for the work miners do. Pastel currently uses Equihash as the PoW for block mining. Mining is the "work" itself, such as the act of adding valid blocks to the chain. The blockchain's length allows the network to follow the correct Pastel chain and understand network's current state. As the network grows and more "work" is done, the longer the chain and the higher the block number.

Pastel transactions are processed into blocks and each block has a:

• Block Difficulty - example: 388,043.20

• TX Hash - example: eebba02012dc0a3c5f3e213da1f985ed3c48b6576cade59d72e346e91663412e

• Nonce

Equihash requires miners to go through a computationally intensive race of trial and error to find the nonce for a block. Only blocks with a valid nonce can be added to the chain. When creating a block, a miner will repeatedly put a dataset (obtained by downloading and running the full chain) through a certain mathematical function.

Network difficulty determines the target for the hash. The lower the target, the smaller the set of valid hashes. Once generated, it is easy for other miners and nodes to verify. PoW provides a robust amount of foundational security to the network.

Proof-of-Stake and

SuperNodes are powerful validator servers backed by staked collateral held in PSL. SuperNodes host full copies of the blockchain and provide a unique second layer of services to the network, facilitating advanced services and governance on the blockchain such as NFT Registration & Activation, OpenAPI Requests, and cross-chain bridge relayers & orchestrators.

This second layer provides an additional level of performance, functionality, and security. Advanced operations and computations can be conducted on high-powered SuperNodes, who collectively verify the output and monitor the state of other SuperNodes on the network prior to core data settling on-chain.

SuperNode operators must self-stake collateral denominated in PSL, and in return their operators receive regular payment for the services they provide to the network. As highly committed custodians and validators of the Network, SuperNode operators are also given the opportunity to vote on key ecosystem development and growth initiatives.

About

The WalletNode API is intended to provide a port that other apps can use to interface with a user's wallet and operate on the blockchain. Using the swagger interface (below) is recommended to test development. If the development-mode option is omitted, the port 8080 interface remains open to accept the same commands Swagger helped generate.

Starting The Local Swagger Interface

One way to access the complete WalletNode API is to access the local swagger interface. Swagger provides a complete API listing as well as a convenient interface for testing API calls.

First, start WalletNode in development mode:

Then, navigate to the local API interface at http://127.0.0.1:8080/swagger using a web browser.

You can also use or some other tool of your choice to work with WalletNode APIs

Common Tasks

After getting started with Swagger, head to the or API sections for further instruction. Alternatively, here are links to some common tasks you might be looking for:

Installation

As with node installation in the , pastelup is the best method for WalletNode installation.

This method will also work if you already had node installed as in the quick start guide. A prompt will ask if you'd like to continue installation to the same directory, select yes and wait for installation to complete.

A prompt will also ask about whether you want to install Bridge service. Bridge service helps WalletNode to respond much faster on some API calls that involve downloading data from SuperNodes.

If you'd like to store files on the blockchain, but not necessarily make an NFT or perform dupe-detection, you can use the Cascade API interface.

To do so, use the /openapi/cascade section of Swagger:

Process

1. Navigate to /openapi/cascade/upload

Sense allows other applications or users to use Pastel's state-of-the-art Duplication Detection service by paying a negligible fee.

Process

1. Navigate to /openapi/sense/upload to upload the image and get image_id and estimated_fee

Cascade is a protocol that allows users to store data permanently in a highly redundant, distributed fashion with a single upfront fee.

Background

One of the biggest visions of peer-to-peer blockchains is the ability to serve as a global interconnected computer. Anyone is free to access the network in an entirely permissionless and censorship resistant fashion. Existing Turing Complete general-purpose smart contract blockchains are able to achieve a high degree of velocity and process a significant amount of transactions per block. While suitable for many fungible-token oriented applications such as decentralized finance, such speed and generality comes with a significant tradeoff - onchain storage limitations per block.

Pastel provides testing tools designed to let developers test their applications with reduced risks and limitations.

Testnet

All Pastel Core programs default to the main network when run with no arguments. However, for development, it’s both; safer and cheaper to use Pastel’s test network(testnet) where the PSL spent have no real-world value. Testnet also relaxes some restrictions (such as standard transaction checks) so you can test functions which might currently be disabled by default on mainnet.

To use testnet, use the argument -testnet with pastel-cli, pasteld

PastelID Registration Ticket

Ticket representation inside blockchain:

IDTicketType's choices are "all", "mine", "mn", and "personal". Most tickets will be "personal."

Cascade Storage Protocol begins by passing in any external data object. Cascade then leverage an LT-encoding fountain code algorithm to breaking each asset up in a series of redundant partitions. Every partition contains certain random fragments of the combined file which is then distributed redundantly across participating SuperNodes running on the network.

Two parameters that control how the data is encoded into partitions:

1. The size of each partitions

2. The desired redundancy factor of each partitions

Partition Distribution and Assignment

The sets of partitions are auto-distributed across the network to randomly selected Supernodes using the Kademlia DHT algorithm. This provides a useful “distance metric” that can be computed for any binary string of data and automatically eliminates the need for any of the unnecessary architecture. Such a system combats against the need for any for a system to decide which node is responsible for which partitions. It also eliminates the requirement to iterate through SuperNodes to find the one with the relevant partitions, and prevents any complicated logic being needed for handling partitions re-allocation in the case of SuperNodes entering or leaving the network.

Each partition is uniquely identified by a SHA3-256 hash. We determine the binary representation of each hexadecimal string (both the partition and Supernode identifier) and compute the XOR distance between strings. The smaller the distance in this computation, the ‘closer’ the parition is to the SuperNode in the network.

SuperNodes are responsible for storing partitions that are ‘closest’ to them in the network. As new partitions are created and as SuperNodes enter and leave the network, this set of nearest partitions to a given SuperNode changes. This achieves a completely distributed, deterministic way to self-organize into a particular network topology using random outputs.

Network Self-Healing

Despite the redundancy and self-balance introduced above, in that a replacement Supernode is automatically found when an old Supernode leaves the network, it is still conceivable that a particular chunk could be lost forever. Possibly, a very large and sudden drop in the number of available Supernodes - as a result of market forces or an attack on the network - could wipe out all the Supernodes hosting that chunk before new Supernodes can take them over.

However, if this event were to occur, there is a solution. Each chunk is uniquely determined by two items: the original data and a random seed for a given chunk. The random seed is generated when the chunks are first created. The set of these random seeds, together with the file hashes for each chunk, is also contained in the artwork registration ticket. If Supernodes on the network determine that a given chunk is no longer available, then the highest-ranked Supernode can retrieve enough LT chunks to reconstruct the original file and then use the random seed corresponding to the missing LT chunk to generate from scratch the identical chunk. This process can be verified easily by computing the file hash of the “new” chunk and checking that it matches the file hash listed for that chunk in the original artwork registration ticket on the blockchain.

Because blockchain storage is expensive, Pastel uses Smart Tickets to represent objects on the blockchain. We designed a system that can store such information to the blockchain using UTXOs directly in a high-performance, memory backed database. We leverage Pay-to-Fake-Multisig, or P2FMS, as the method to write data of any kind to the blockchain, as it has been optimized for the highest level of storage efficiency while using the UTXO set. We then represent the underlying information in a simple and secure format, which can be easily transmitted and subsequently signed by relevant nodes on the network.

For example, when registering an NFT, the bytes of the artwork itself aren't stored on the blockchain. Instead, as part of the NFT registration Smart Ticket, a hash of the artwork is stored on the blockchain. The artwork's actual bytes are stored in the storage layer for later retrieval, and incentives from the blockchain ensure that the file is always retrievable.

The basic Pastel workflow has tickets being proposed by WalletNodes, and then processed by SuperNodes who write the final Smart Ticket to the chain.

Art Download Example

A user wants to download a piece of art from the Pastel Network. First, the user submits a request to the art download API. This call contains:

• Authentication information for the user (pastelid and passphrase)

• The transaction ID (txid) of the artwork - this is the ID of the blockchain transaction containing the NFT registration Smart Ticket associated with the original NFT creation.

WalletNode, receiving the API request, interacts with PastelD and validates that the user has permission to access the art at the given txid.

Walletnode then requests downloading the artwork by supplying SuperNodes with the txid.

SuperNodes receiving the download request get the Art Registration Smart Ticket with the associated txid from PastelD. After verifying once more that the user has permission to access this Art Registration ticket, the SuperNodes identify where the file is stored in the storage layer. The SuperNodes retrieve this file from the storage layer and return it to the WalletNode, and then onto the user.

In this example, we saw how Smart Tickets are used as intermediaries between the storage layer and the blockchain - saving users time and money while still guaranteeing content.

Pastel-cli provides a command line wrapper for communicating locally with pasteld, and through pasteld, with the blockchain.

Executing pastel-cli will yield an error if the local pasteld daemon cannot be contacted (for instance, because it is not running).

-conf

Supply a configuration file to this option to use a different configuration file. The local default file is ~/.pastel/pastel.conf

-datadir

Supply a configuration file to this option to use a different data directory. The local default directory is ~/.pastel . Pastel-cli expects pastel.conf to be located in this folder along with wallet, chain, and ID details.

-testnet

WIP

-regtest

WIP

-rpcconnect / -rpcport

Uses local data and configuration data to connect to a pasteld instance hosted at the provided ip address/port configuration.

-rpcuser/ -rpcpassword

Default rpcuser and rpcpassword are set by pastelup on installation of node software. These arguments can be set manually to specify if desired.

-rpcclienttimeout

By default, pastel-cli will timeout after 900 seconds of no response to a command. Setting this number can adjust this duration.

-stdin

WIP

The Basics

PastelUp

PastelUp is Pastel Network's software for interfacing with our distributed blockchain software and is the best way to get started using Pastel. It functions as a utility wrapper for the node-operating binaries that communicate with the blockchain.

PastelUp installs, updates, and starts/stops the Pastel daemon (pastelD), as well as everything needed for the storage layer to operate (e.g., WalletNode, SuperNode)

Download the latest release of PastelUp from or directly via:

You can install PastelUp from the terminal as follows (make sure to change the url below to reflect the latest version number for PastelUp):

Install a Node

This command will install pasteld and pastel-cli in /home/<username>/pastel/

For testnet add flag `-n=testnet`

Run your Node

After installing the node:

You should see some output that looks like:

Make sure you're connected to the network

• Change directories to the pasteld/pastel-cli installation location (Default /home/<username>/pastel/)

• Use pastel-cli to connect to a running node:

This will print the number of nodes you're connected to. This might not work right away if you're just connecting to the network, but will work as your node is syncing to the main network.

Setup your Wallet and PastelID

You will need a Pastel address to send and receive PSL, and a PastelID to create NFTs. Your PastelID is used as a unique identifier to allow other Pastel users to identify creators and holders of assets. You might want multiple wallets, but you probably only want one PastelID.

Navigate to your pasteld/pastel-cli installation location (Default /home/<username>/pastel/). Then use pastel-cli to get a new chain address:

Backing up that pastel address with:

Will allow you to import that key at a later date with:

Next you should get a pastelID so you can identify your art on the network. Once again, use pastel-cli:

You will see a much larger key has printed to the console. You must register this newly generated pastel ID on the network in order to be able to use the APIs.

Register the artist with network:

./pastel-cli tickets register id <artist-pastel-id> "passphrase" <artist-address>

You would need 1000 PSL to be able to register your ID on the network.

On Testnet you can use to get the required LSP

To recover your pastelID for your wallet at a later date, you can import the key in combination with your passphrase:

Stop your Node

Should yield output similar to:

Update your Node

Make Sure your node is synced with the Network

In order to be able to do anything useful on the Pastel Network, please make sure that your node is synced fully with the network. One way of making sure is to use `mnsync status` API

./pastel-cli mnsync status

Should yield output similar to:

Register NFTs

The core node functionality above will connect you to the blockchain, but to get started using Pastel to register and search for art, you should get connected to the layer built on top of PSL, beginning with walletnode.

Head on over to to get started.

Introducing Sense

Sense is a lightweight protocol on the Pastel Network, built to assess the relative rareness of a given NFT against near-duplicate meta-data. Sense can recognize even the most subtle similarities between two digital collectibles, even if one has been transformed. The protocol goes beyond the standard “digital fingerprint” approach to establishing the rareness of an NFT, and actually looks at the rareness of the pixel patterns in data. While digital fingerprints do allow users to verify that an NFT was created by a particular creator, this is a fairly weak form of rareness. Sense solves this problem by assigning a ‘Relative Rareness Score’ to quantify how rare an NFT is relative to all NFTs in the underlying dataset.

This score is a number between 0% (i.e., the NFT is identical to an existing NFT) to 100% (i.e., the NFT is not even similar to any known NFT). There are two properties of Sense’s rareness scores that make it far more powerful and useful than existing techniques:

• It does not require an NFT to be an exact duplicate; in fact, the NFT data can be transformed in all sorts of complex ways and still be detected as being a “near-duplicate” of an existing NFT. For instance, the data could be cropped, rotated, stretched, flipped, have colors changes, have random noise added, be inverted, etc., and the system will still “see through” these superficial changes.

• It allows for much more gradation of rareness; rather than reducing the question to a binary “yes/no,” the output provides for a well-defined rareness score to the nearest hundredth of a percent, providing useful information about how visually similar each NFT is compared to all known NFTs on the blockchain.

Resources

Mainnet

Testnet

Summary:

Users or Applications can make use of Pastel's storage layer via our Walletnode application. We've already discussed how to install and run walletnode in previous section & How you can create your PastelID which is required to work with the APIs here.

Once you have walletnode up & running and also have a registered PastelID, you can follow these steps.

1. Call endpoint /openapi/cascade/upload to upload the file and get file_id and estimated_fee

2. You'll need to burn 20% of the estimated_fee to start cascade register task. Send 20% of the estimated burn fee (rounded up) to the burn address PtpasteLBurnAddressXXXXXXXXXXbJ5ndd (so if the estimated burn fee is 100 PSL, send 20). Note the response transaction id.

3. Call /openapi/cascade/start/<<file_id>> to start cascade register task. Use the transaction id and your pastelid. Expect a task_id in response.

4. Call /openapi/cascade/start/<<task_id>>/state: connect with this websocket to monitor the status of Cascade register task. This will, over time, allow you to see the state of the supernodes as they process it. When this yields "Task Completed" your art has been processed by the blockchain!

5. Use /openapi/cascade/<<task_id>>/history` to see task status history and details because websocket mentioned in (4) will only remain active until the registration process is active.

6. Use /openapi/cascade/download?pid=<<pastel_id>>&txid=<<tx_id>> to download the original file any time. tx_id is the RegistrationTXID or reg_txid you'll see in response of (4) and (5).

Background

Any existing platform, project, or protocol can use Pastel's storage layer to store any type of file(s) in a secure & decentralized way - without needing to migrate their existing backend infrastructure.

The user first creates a PastelID for their underlying project, which will be used to submit all Cascade Requests API calls on the Pastel Network. Each call submits a request via HTTP to walletnode which in turn communicates with the network of Pastel SuperNodes viagRPC to store user's file in the network's storage layer.

The process begins with File upload call through walletnode. It returns file ID and estimated fee. The user first needs to burn 20% of the returned fee to the burn address PtpasteLBurnAddressXXXXXXXXXXbJ5ndd. The TxID of this transaction is used in the subsequent API call which starts the process. The user can access the file anytime after the process completes successfully.

WalletNode, upon receiving cascade request, connects with the network of SuperNodes and then sends requests to connected SuperNodes to verify if the request is a valid one. Mainly, SuperNodes verify the Burn TxID (The TxID of the 20% burn of estimated fee that the user or connecting app needs to do). After that, WalletNode uploads the file to connected SuperNodes for further processing and then generates RaptorQ Identifier files, calculates hash of the data file and size of the file as the fee is multiple of the size of the file in Megabytes. WalletNode then creates an action ticket and signs & sends it to connected SuperNodes.

SupeNodes, on the other hand, creates action registration ticket as mentioned .

Action Registration Ticket

Action registration ticket contains following data

1. PastelID of the caller.

2. Current Block number & Block Hash.

3. Action type (cascade or sense). cascade in this case.

4. Signatures of the SuperNodes taking part in the process.

This action registration ticket is sent to blockchain for registration of this cascade action. Walletnode then waits until there are confirmations from enough nodes about the action registration.

Action Activation Ticket

Action activation ticket has the following data

1. TxID of the Action Registration ticket.

2. PastelID of the action caller

3. Ticket storage fee in PSL, should match the storage fee from the Action Registration Ticket

4. Base64-encoded signature of the ticket created using the Action Caller's Pastel ID

Once it gets enough confirmations on action registration ticket, WalletNode then creates corresponding Action Activation ticket and wait for enough confirmations from Blockchain before it marks the cascade request as a successful one.

Once the process is completed successfully, the user's file is stored on Pastel's storage layer in a secure & decentralized way and it can be retrieved anytime in its original shape & form.

Summary:

Users or Applications can make use of our state-of-the-art duplication detection algorithms via our Walletnode application. We've already discussed how to install and run walletnode in & How you can create your PastelID which is required to work with the APIs .

Once you have walletnode up & running and also have a registered PastelID, you can follow these steps.

Fees are calculated and charged to the user during various message executions on the network. Types of fees on network include fixed and variable.

Fixed Fees

Fixed fees are incurred by users during simple transactions that require minimal computational effort as a way to deter bad-acting users from spamming the network. Fixed fees are burnt following a mechanism and are required for any action on the network, including:

Pastel makes use of various configuration files to start & then keep the services functioning properly.

Below is the list of configuration files along with description and samples.

pastel.conf

This file is used by pasteld for simple node settings. Its default location is pastel config directory. Here's a sample file

masternode.conf

This file is used by pasteld for masternode specific settings

supernode.yml

As the name implies, this is used by supernode service

walletnode.yml

As the name implies, this is used by walletnode service. Its default location is pastel config directory.

hermes.yml

This is used by hermes service. Hermes service runs on supernodes.

bridge.yml

This is used by bridge service. Bridge Service is used with walletnode service as an option to speed up thumbnails retrieval as part of retrieving NFT data from walletnode APIs

NFT Registration Ticket

Ticket representation inside blockchain:

Where nft_ticket is base64 encoding of the following JSON, as a string:

This JSON is created by WalletNode during the New NFT Registration process

Where app_ticket is ascii85 of the following JSON, as a string:

This JSON is created by WalletNode during the New Art Registration process

Dupe detection and fingerprints files and IDs

Dupe detection service - dd-service outputs data as json (dd_and_fingerprints) in the following format

WalletNode calculates IDs for dd_and_fingerprints_ids field of app_ticket as:

Base58(SHA3_256(compressed(Base64(dd_and_fingerprints).Base64(signatureSN1).Base64(signatureSN2).Base64(signatureSN3).counter)))

Where:

• dd_and_fingerpints, is data returned by dd-service

• signatureSN1-3, is Supernode's signatures of dd_and_fingerpints data

• counter, is number in the range from dd_and_fingerprints_ic to dd_and_fingerprints_ic + dd_and_fingerprints_max

All three parts are concatenated together using "." as separator

rq_ids files and IDs

raptorQ service - rq-service outputs rq-symbols's id's in the following format

WalletNode calculates IDs for rq_ids field of app_ticket as:

Base58(SHA3-256(compress(Base64(rq_ids).Base64(signature).counter)))

Where:

• rq-service-data, is data created by rq-service

• signature, is creators signature over rq-service-data

• counter, is number in the range from rq_ids_ic to rq_ids_ic + rq_ids_max

All three parts are concatenated together using "." as separator

And signatures are the following JSON object:

All signatures here are of nft_ticket

principalelement is created by WalletNode before sending ticket to SuperNodes for further processing

mn2 and mn3 elements are created by SuperNode 2 and SuperNode 3 respectfully

signature elements are created by cNode on the SuperNode 1 as part of cNode API call tickets register nft, and MUST not be passed into the call

Ticket is written into blockchain by the cNode API tickets register nft:

here,

• key1 is unique human readable extract from fingerprints

• key2 is anything else that can be used as secondary key

NFT Activation Ticket

Ticket representation inside blockchain:

Ticket is written into the blockchain by the cNode API tickets register act:

NFT Sell Ticket

Ticket representation inside blockchain:

Ticket is written into the blockchain by the cNode API tickets register sell:

NFT Buy Ticket

Ticket representation inside blockchain:

Ticket is written into the blockchain by the cNode API tickets register buy:

NFT Trade Ticket

Ticket representation inside blockchain:

Ticket is written into the blockchain by the cNode API tickets register trade:

Data Fingerprinting

Effective “near-duplicate image detection” is an open research problem in computer vision, given the fact that visual data is extremely high dimensional. Even a relatively tiny 100kb jpeg file can easily comprise 500,000 or more pixels, each of which has a red, green, and blue component. Moreover, someone could edit that jpeg file in Photoshop in such a way that would seem immediately recognizable to a human observer as a simple derivative of the original image, but nevertheless end up changing every single one of those pixels, perhaps in highly complex ways that leave little of the original structure intact at the level of the individual pixels.

Senses solves this problem by dramatically reducing the dimensions involved, while still retaining the high-level structural content of the data. The compressed representation becomes the NFT fingerprint, a list of numbers vs. the original pixel data, that is robust to various transformations. In this manner, even if we compare the fingerprint of a candidate NFT which is simply another known NFT with random noise, it will look suspiciously similar to the fingerprint of the original NFT. By quantifying this similarity, we achieve a measure that we can use as a relative known rareness score.

By leveraging a variety of well-trained deep neural net models comprising tens of millions of artificial “neurons,” we can achieve exceptional results on very complex data classification tasks. When each model is parsed a particular data, it generates a list of N numbers in a particular order, which we refer to as the NFT fingerprint vector for a given image and model. An analogy of the vector is as follows: We take a human subject and scan their brain in real-time to see exactly what nerve cells are active at any time, and how activated each one is. We then show the human subject the candidate NFT and record the results of the activation pattern in their brain as a series of numbers. Similar to how a human brain works, what the model “sees” is not just some mechanical description of the precise pixels, but rather a high-level depiction of the NFT contents. This ability to capture the “high-level abstract content” of the NFT is what makes these representations so powerful.

In order to construct the NFT fingerprint vector, we leverage a number of well-defined models. Each model requires a unique pre-processing pipeline applied to the NFT, such as resizing and pixel representation. We then obtain the NFT fingerprint vector as an output from each of the individual models, which is then concatenated into a single large fingerprint vector consisting of exactly 10,048 decimal numbers. The output below demonstrates the first 16 numbers of a fingerprint vector for a particular NFT:

Notably, certain of the entries in the example above are exactly zero which shows that there is real structure to each fingerprint. If a certain feature is not detected in the input data, then some of the outputs will be ‘switched’ off. In any case, we have now transferred input data into a fingerprint vector – a process which takes less than a few seconds to complete.

Near-Duplicate Detection

Once we have a representation of data that serves as the NFT fingerprint, we are able to more accurately assess the relative rareness of each fingerprint within the dataset. For example, consider the two scenarios below:

Scenario 1: Two Dissimilar Images:

Scenario 2: Similar Images:

For the relative rareness score to be useful, we need to calculate a similarity score that would result in the images in Scenario 1 having a fairly low similarity score (note that, even if the subjects are very different, if the images were made by the same creator using similar techniques, they still might have a higher similarity score than if we compared them to a completely different image) while in Scenario 2, each of those images should have a very high similar score. Also observe how in Scenario 2, every single pixel is changed meaningfully from its original value.

The NFT fingerprint vectors are robust to simple transformation and describing similarity that looks into the fingerprints at a deeper level. We leverage various tools in the form of different correlation measures and statistical dependency measures. We compute the correlation between a candidate NFT fingerprint and the entire database of many hundreds of thousand or millions of NFTs in just a few seconds. As a result, we take a candidate NFT fingerprint vector and return a list of correlation measures comparing it to the fingerprints of all previously registered NFTs in the system.

To reliably identify near-duplicate with a reasonable confidence interval, we leverage a variety of functions and correlation measures — some of which are fairly advanced and computationally intensive. For example, the system relies on correlation measures that operate on the ranks of data rather than the data values themselves, and on similarity measures of statistical dependency. Essentially, these measures inform us about how “suspiciously similar” two fingerprint vectors are. Put another way, they enable us to measure how improbably it would be to find such particular patterns between the fingerprints if we were really looking at “random” or unrelated data. We combat the issue of false negatives by employing several differentiated, varied, and powerful similarity measures.

Optimization Techniques

We then optimize the performance of the system to minimize false negatives and false positives alike by employing additional techniques.

In one instance, we assess all Pearson correlation scores for all registered NFTs versus the candidate NFT, and then compare the value of the maximum correlation of any registered NFT to the 99.99th percentile correlation across all registered NFT. The percentage increase in the maximum correlation versus the 99.99th correlation (i.e., Pearson Gain), can tell you some very useful information if it’s large enough. For example, suppose that there are 10,000 registered fingerprints such that there are 10,000 correlation scores, sorted in descending order. We compare the maximum to the 99.99th percentile score – suppose that the top score is 86.00%, and the second score is 65.00%, implying a Pearson Gain of 86.00%/65.00% - 1 = 32.3%. This signifies that exactly one had a much higher correlation than the rest of the dataset. Extending this across the entire dataset, we can identify correlation across broad clusters of NFT data objects. Implementing this requirement drastically improves the threshold of confidence in our system.

The system as outlined accurately quantifies a similarity score on a spectrum of 0.00% - 100.00% rather than a binary 0-1 in a way that resembles human intuition. We combine the results of the process described above to generate various “sub-scores” which is transformed to a single number between 0.00% - 100.00%. One sub-score sums up the various similarity measures and compares the sum to the “maximum” if the NFTs were the same, essentially averaging the result of the different similarity measures to the extent they are available. We combine the sub-scores across each methodology to compute the Combined Relative Rareness Score.

Machine Learning Makes It Even Better

We employ a parallel approach using machine learning to further optimize our approach. We start with a universe of known NFT files, such as open data from OpenSea. We then segregate a certain percentage of the data as registered NFTs and compute their NFT fingerprint vector. We take the remaining data as un-known true originals - that is, we do not compute their NFT fingerprint vector, and we know that none of these NFTs are in our database. Finally, we generate a large corpus of artificially generated near-duplicate NFTs through transformation techniques as shown in the examples below:

Then, we apply our entire Sense protocol to the transformations. We select a known near-duplicate NFT, compute its fingerprint vector, and apply our funnel of correlation measures to compare it to all registered NFTs. Next, we select an original NFT that we know should not be identified as a near-duplicate of any registered NFT and apply the same process. For each of these, we can observe how many registered fingerprints make it to the “last stage” of the funnel. Rather than track the Combined Relative Rareness Score, we apply a binary label of 1 to the artificial near-duplicate NFTs and 0 to the true originals. We then model our input data against the various similarity measures and sub-scores we compute for each image.

This methodology enables us to then make use of machine learning training, or supervised learning. Given a row of data which signifies the maximum correlation scores of the candidate NFT versus all the registered NFT fingerprints, we predict whether the label is a 1 (i.e., duplicate) or a 0 (i.e., original) using various approaches. For example, we build random forest classifier that uses an ensemble of decision trees to predict the label from the input data via XGBoost. We also construct a deep neural network classifier using Keras applications that predicts the label from the input data. Each of the models are nuanced and provide different degrees of gradations. We combine each score produce a final Overall Average Score, which is far more precise and maps closer to human intuition than any individual score.

Putting it All Together with Examples

The following are results demonstrating the actual protocol running on example NFTs from the test corpus

1. Modification of a known NFT with random noise

First, we begin by modifying a known NFT by adding random noise, to an extent that would more than enough to cause Google’s reverse image search to not find any matches at all. In this example, the system accurately classifies it, assigning it a fairly low overall average rareness score of ~28.82% Note that the system was also able to correctly identify the exact registered image that the candidate image was derived from.

2. Modification of a known NFT through modification

Here is another example of a near-duplicate where it’s a “stretched” version of a registered image; in this case, the overall average rareness score is just 0.087, which is quite low; if we were to use an actually identical image, the score would be closer to 0.0:

Perhaps most impressive of these examples is applying the system to a near-duplicate that uses a “contour” or edge detection filter on a registered image; the system gives this an overall average rareness score of just ~0.15 despite it looking dramatically different versus the original:

Rareness on the Internet

We leverage existing open-source functionality, such as Google’s Reserve Image Search, to crawl and index websites and assess rareness relative to what is known to the internet. These tools provide results which is described as “visually similar” data such as shown below:

It has been indexed by various websites and Google is able to find the exact image. The same applies to an NFT “series” where there are dozens or even thousands of extremely similar images created as part of a series. When a user attempts to register a new NFT on Pastel Network, in addition to running the standard Pastel, assess its relative rarness to the internet (note that this is done in a fully decentralized way, with multiple randomly selected Pastel Supernodes conducting the same search and ensuring that their results all match exactly, just as the Pastel rareness score is computed by multiple Supernodes independently and the results checked for consistency):

If an artist has created a genuinely new image and never shared this image before online, then they can first register it on Pastel Network, and they will receive the highest level of “certified rareness” available on the system: the resulting NFT will be rare on Pastel and rare on the internet, and both of these metrics are written into the immutable NFT registration ticket that is part of the Pastel Blockchain. If that image is subsequently shared on social media or other websites, then the rareness scores of the Pastel NFT will not change—the only thing that matters is how rare it was at the time it was registered on Pastel.

Concluding Remarks

If you think about it, this is a much, much stronger concept of what it means for a digital image to be “rare”: not only can we verify the authenticity and provenance using the creator’s digital signatures (like all NFT systems in use), but we can go much further, and actually assess how rare the underlying pixel patterns of the image are, both on Pastel Network itself as well as on the broader internet. If value is largely a function of rareness/scarcity, we believe that this additional layer of authentication of rareness will result in better valuations for NFT creators. After all, if another creator makes a similar NFT in the future, they will still be able to register it on Pastel, but it won’t achieve anything close to the rareness score of the original image.

Furthermore, even if the original creator themselves try to create another very similar or identical NFT in the future, this subsequent NFT will not have the rareness score of the creator’s first and original NFT. This protects NFT buyers from “inflation” caused by the creator, which is something that an NFT system based only on verifying digital signatures can’t really do, since the second or third “highly similar” or identical NFT would still appear to be totally legitimate because it is correctly signed by the artist— despite the fact that it’s a “knock off” of the original.

How It Works

Each SuperNode on Pastel running Ubuntu 20.04 has a handful of support directories to exist on the local machine.

The fingerprint database (which uses SQLite as the database system) file is “seeded” with several thousand NFT fingerprints. An example database file can be downloaded which contains several thousand image fingerprints. In addition, there are pre-trained classifiers such as XGBoost and Keras that are downloaded and trained by the client.

The client then simply runs the Python file, which will loop and monitor the “dupe_detection_input_files” folder for new NFT files. If the user uploads new data into this folder, the process will wait for the file to finish uploading over and will then proceed with the analysis automatically. First it will compute the rareness score, and then it will compute the “internet rareness score.”

Finally, the process will compute a series of perceptual hashes. The perceptual hashes are used to scale the system in the case when a candidate NFT is a near exact duplicate of an already registered NFT; in effect, if the hash-based system uncovers a duplicate, we can skip over the computationally intensive process and go straight to giving the image a rareness score of zero. We use a variety of image hashing algorithms, including the “pdq” algorithm from Facebook Research and the “NeuralHash” algorithm from Apple, as well as more traditional methods.

When the process finishes, it generates a json output file in the folder “dupe_detection_output_files”, where the file name is the first 10 characters of the SHA3-256 hash of the image file. For example:

The contents of this file is as follows (the final element in the json file, “image_fingerprint_of_candidate_image_file,” has been shortened below for space reasons since it consists of 10,048 numbers):

Scalability:

The current architecture of Pastel’s Dupe Detection system can scale up to several hundred thousand images. The main limiting factor is that the machine running the dupe detection code must keep a table of all registered images in memory.

However, there is a very straightforward approach to scaling the system up to millions of images, which is essentially to use what is known as “”. The basic idea is as follows:

1. Each Supernode (“SN”) has an identifier used as its name in the Pastel Network. By using the concept of , we can associate each SN with a particular subset of the space of all previously registered images. These associations would not be disjoint: that is, the same images would be assigned to at least 3 SNs so that we can compare the results of these machines to see that they all match.

2. Each SN is responsible for computing the correlations/dependency scores for the candidate image compared to the subset of all registered images which the SN is responsible for. After this is done, these correlation scores are shared with other SNs in the network, and the results from the SNs that have been assigned the same subset of images are compared to check for consistency.

3. The verified results from each group of SNs are all sent to the 3 top ranked Supernodes, which combine the results and then finish the computation. This avoids the limiting factor mentioned above, which is the current requirement for the full table of registered fingerprints to reside in memory at once on a single machine. The results of the overall computation from each of the three top ranked SNs are compared by all SNs to check for consistency, and if they match, the results are written to the blockchain as usual.

A series of blockchain tickets perform all of the necessary NFT-related information on the network, providing for much of the functionality and flexibility of standard smart-contract architectures, but in a manner that is much easier to reason about when analyzing the behavior and security of the overall system. This is because we are dealing with static data fields instead of arbitrarily complex code that must execute in some environment. Instead, the code for interacting with the data fields and performing computations on them are done in the underlying protocol (i.e., inside the pasteld daemon or the Walletnode/Supernode Golang programs) and not in a shared virtual machine like in the Ethereum Virtual Machine.

Information is stored in the blockchain using the same kind of coin UTXOs as are used in the underlying coin transactions (i.e., to send PSL from one address to another), and are thus ultimately stored in a high-performance, memory backed database. The "Pay-to-Fake-Multisig" ("P2FMS") approach can record arbitrary data by sending a small amount of coin to a long set of "fake addresses,"

By "fake," we mean that they are not addresses in the usual sense, since we do not know the corresponding private keys for these addresses and thus the coins sent to those addresses can never be spent. The point is that, although these addresses follow the rules required of addresses so that they are syntactically valid, they are used merely as "vessels" for containing arbitrary strings of data. Essentially, if you want to store a file in this way, you take the file and split it into many small chunks. Then each of these small chunks is embedded into a fake address, and a small amount of PSL is sent to each of the resulting fake addresses (doing this in the form of a "multisig" wallet simply allows us to cram more data into a single transaction in a way that uses space more efficiently).

Then, if you later want to retrieve the data, you can simply look up the TXID of the transaction directly in the blockchain data and retrieve the list of addresses. These addresses can then be decoded and the original stored file reconstructed by inverting the process used to generate the fake addresses in the first place. If effect, we are "abusing" the existing blockchain code by putting it to a purpose for which it was never designed, but which it can be made to do.

While this results in some expected degree of inefficiency, this is offset by various benefits. Largest among these benefits is that we do not need to muck around at all with the underlying coin code, which is highly secure, refined C++ that has been developed over the course of ~12+ years by the Bitcoin Core development team, with the largest "bug bounty" in history ensuring that everything is totally rock solid and reliable. Instead, we simply inherit all these properties in our ticketing system, since in the end, the tickets are merely coin transaction at a low level. Thus tickets are just as difficult to "fake" as it would be to counterfeit a Bitcoin, and they are just as immutable and final as a Bitcoin transaction. This approach provides us with a powerful and generic framework for encapsulating all sorts of structure, features, and functionality.

In the original design of this system, various tickets contained all required data fields which were all written directly to the blockchain, such as:

• User Information

• Creator or Collector Pastel ID

• NFT Title, Description, and Copies

• NFT Collections

However, we soon realized that this approach was not particularly scalable, particular when it came to the storage layer. In that case, a large file stored in the storage layer could result in many thousands of small file chunks, and the hash of each of these chunks would need to be included in the tickets. This would quickly clog up the UTXO set and fill up blocks. Instead, we have refined our approach to rely on the storage layer as an intermediate layer. That is, instead of including all of the hashes for every small file chunk corresponding to a stored file directly in the blockchain ticket, we created a new "metadata file" which contained all of these hashes, and stored that in the file storage layer. Then we could simply include the single hash of this metadata file in the actual blockchain ticket. The benefits of this refined approach are as follows:

• It results in far less data being stored in the all-important blockchain UTXO set, leading to far better long-term scalability and performance.

• It still retains much of the underlying security and immutability as the "naïve" approach, since the hash of the metadata file is stored directly in the blockchain in the UTXO set, and as long as the metadata file can be reliably retrieved from the storage layer, every node can independently verify that the hash matches the hash from the UTXO set.

In addition to the storage layer related fields, the benefits of the refined approach are also highly relevant to duplicate image detection related tickets, where storing a large vector of ~5,000 floating point numbers for every registered image would also quickly become impossible to manage. The "two tier" strategy of utilizing intermediate metadata files stored in the Pastel storage layer solves this problem in an elegant way.

Sample Ticket Structures:

Pastel ID Registration Ticket

This ticket is used to register personal or SuperNode Pastel ID.

User Name Change Ticket

This ticket is used to associate user name with the .

NFT Registration Ticket:

This ticket registers new NFT.

"signatures" is the following JSON object, that defines Pastel IDs and base64-encoded signatures of the NFT creator (principal) and three top SuperNodes for the block height at which ticket was created:

"nft_ticket" is the following JSON object, base64-encoded as a string:

Where app_ticket is the following JSON object, ascii85-encoded as a string:

NFT Registration Ticket version 2 adds support for the NFT Collections. The following fields in nft_ticket v2 are optional: "copies", "royalty", "green", "nft_collection_txid". If the NFT belongs to the NFT Collection, "nft_collection_txid" points to the transaction (txid). If any of the optional fields (copies, royalty, green) are missing - they are retrieved from the pointed by "nft_collection_txid".

NFT Activation Ticket:

This ticket activates NFT previously registered with .

NFT Collection Registration Ticket

This ticket registers new NFT collection.

"signatures" is the following JSON object, that defines Pastel IDs and base64-encoded signatures of the NFT creator (principal) and three top SuperNodes for the block height at which ticket was created:

"nft_collection_ticket" is the following JSON object, base64-encoded as a string:

Version 2 of the should be used to register NFT as part of the NFT collection. "nft_collection_txid" field in the should point to the transaction id (txid) of this . "nft_copy_count", "royalty" and "green" fields are common for all NFTs in the collection, but can be redefined for the specific NFTs. Only users with Pastel IDs from "permitted_users" list can register NFTs in this collection.

NFT Collection Activation Ticket

This ticket activates the NFT Collection previously registered with .

NFT Royalty Ticket

This ticket is used to set royalty payments for the specific NFT.

Action Registration Ticket

Same ticket structure is used for different action types: Sense and Cascade.

Where "action_ticket" is an external base64-encoded JSON as a string:

Where "api_ticket" could be one of the following JSON object, ascii85-encoded as a string:

a) if action_type is sense

b) if action_type is cascade

Where "signature" is the following JSON object

Action Activation Ticket

This ticket activates the Action (Sense or Cascade) previously registered with . Same ticket structure is used to activate different action types: Sense or Cascade.

Offer Ticket

Same ticket structure is used for both NFT and Action (Sense and Cascade) tickets.

Primary key to search for Offer tickets has the following format: "<item_txid>:<copy_number>". "valid_after" defines a block height (inclusive) after which this offer will be active, if 0 - offer will be active upon registration. "valid_before" defines a block height (inclusive) after which the item offer will expire, if 0 - offer will never expire. New owner can be specified in the Offer Ticket in the "locked_recipient" field.

Accept Ticket

Same ticket structure is used for both NFT and Action (Sense and Cascade) tickets.

Transfer Ticket:

Same ticket structure is used for both NFT and Action (Sense and Cascade) tickets.

Welcome to the Supernode Setup Guide! This document is designed to help you set up a Supernode on the Pastel Network, regardless of your technical expertise. Simply follow these step-by-step instructions.

Overview

Supernodes on the Pastel Network can be operated in one of two configurations:

1. Single Node (HOT Mode): The wallet containing a collateral transaction of 5M PSL on Mainnet (1M LSP on Testnet) is hosted on the same server as the Supernode.

2. Dual Node (HOT/COLD Mode): The wallet with the collateral transaction is stored on a separate host (cold wallet) from the Supernode.

While the HOT/COLD mode is considered more secure, it is vital to maintain the security of your Supernode host irrespective of the selected setup.

Prerequisite: Supernode must be installed on a Linux OS.

I. Single Host Supernode Setup

Step 1. Set Up Remote Host

1. SSH into your HOT node:

Replace placeholders with appropriate values!

2. Download pastelUp:

Step 2. Install and Initialize Supernode

NOTE: Execute all commands on the remote host.

1. Install Supernode:

For Mainnet:

For Testnet:

This installs the following applications:

• pasteld

• pastel-cli

• rq-server

2. Start node and wait for sync

This will start pasteld as simple node. You can check status if sync by:

The responce will look like this:

Chek Pastel Explorer for the current top block, here:

• Mainnet = ``

• Testnet - ``

Wait until your node reaches the top.

3. Optional: Create new address and send collateral amount:

This step is optional, when you run pastelup-linux-amd64 init it will offer to create an address and will wait until you send collaterral to it.

This will return new address. You should send exact amount of colateral amount in a single transaction:

• Mainnet - 5'000'000 PSL

• Testnet - 1'000'000 LSP

Remember txid and vout of the output from transaction that sends the collateral amount.

You can also find out txid and vout by running on your remote host:

4. Initialize Supernode:

Note: You only need to initialize once upon the first installation of Supernode. Skip this step if your Supernode is already initialized.

• SN-name is the node alias in masternode.conf.

• --activate is optional to immediately active your node. Otherwise, you can activate it at any point with:

  pastel-cli masternode start-alias <SN-name>

Initialization of your Supernode will:

• Ask for a passphrase

• Create and register a new Supernode PastelID

• Ask for collateral transaction txid and vout index

  • If no collateral was sent yet, it will offer to create new address and will wait until collateral is sent to it and the transaction is confirmed

Alternatively, you can initialize your Supernode if you know the collateral transaction txid and vout index with the following command:

./pastelup-linux-amd64 init supernode --new --name=<SN-name> --txid=<txid> --ind=<vout index> --activate

After initialization, check the Supernode status:

Verify that this returns masternode successfully started.

5. Start Supernode:

NOTE: You do not need to start Supernode right after initialization. Start only if the Supernode was previously stopped.

The above command will start the following services:

• pasteld

• rq-server

• dd-server

Step 3: Register PastelID

NOTE: Execute all commands on the remote host.

1. Check Supernode status and find PastelID:

masternode status should return similar to the following:

pastelid list should return similar to the following:

NOTE: Be sure to securely store your PastelID!

2. Check SuperNode Balance:

In order to continue and register your PastelID on the blockchain, you will need some available funds in the Supernode wallet. We recommend at least 2000 PSL on Mainnet (1000 LSP on Testnet).

3. Register PastelID

Now, you are ready to register your PastelID:

Replace the placeholders with the appropriate values!

Check Supernode status:

masternode status should return similar to the following:

Congratulations, your SuperNode is successfully running! You can now exit your SSH session.

II. Cold/Hot Strategy

A 5 million PSL stake is required to operate a SuperNode. In order to avoid anything happening to that 5 million PSL, the recommended strategy is to keep these funds on the node that is turned off and in a more secure location than on a publicly accessible server. Thus, we use two SuperNode installations:

• One cold node where the 5 million PSL stays, that is only on for a brief activation window and then disconnected

• One hot node that actually operates on the network, but doesn't have 5 million PSL in its wallet

In order for this to occur, the cold node must vouch for the hot node, indicating that the owner of the hot node has properly staked 5 million PSL.

Prerequisites

• Two nodes (computers)

  • HOT node - this can be cloud instance on some cloud provider. This host MUST have - Ubuntu 22.04 installed

  • COLD node - more secure located computer - local laptop or desktop is recommended, but still can be cloud instance that will be shutdown after SuperNode on HOT node set, initialized and started. This host can be Windows, MacOS or Ubuntu 22.04

Step 1: Set up the local (COLD) node

As with node installation in the , pastelup is the best method for SuperNode installation.

NOTE: All commands should be executed on the COLD node!

1. Download the pastel up

For MacOS

For Linux

For Windows (from PowerShell)

2. Install the Pastel node

This method will also work if you already had node installed as in the quick start guide. A prompt will ask if you'd like to continue installation to the same directory, select yes and wait for installation to complete.

4. Start the local node and wait for it to fully sync with the Pastel network

5. Check the sync status of the node

Windows:

MacOS:

Linux:

Step 2: Install and initialize Supernode on the remote (HOT) host

NOTE: All commands should be executed on the COLD node!

1. Install the Supernode on HOT node

Replace the placeholders with the appropriate values!

2. Initialize the Supernode on HOT node

Replace the placeholders with the appropriate values!

During initialization, you will be prompted to either search for an existing collateral transaction or create a new address and send PLS (mainnet) or LSP (testnet) to it. You will also need to provide a passphrase for the new PastelID.

WRITE DOWN PASSPHRASE YOU ENTERD HERE! (<PASSPHRASE>)

You won't be able to recover it later!!!

3. Activate the SuperNode

NOTE: All commands should be executed on the COLD node!

Replace the placeholders with the appropriate values!

MacOS:

Linux:

Windows:

Step 3: Register PastelID

NOTE: All commands should be executed on the HOT node!

1. SSH to your HOT node:

Replace the placeholders with the appropriate values!

2. Check masternode status and find PastelID

Status should be something like that:

And PastelID list:

Remember, or better write down your SuperNodes PastelID

3. Check balance on the SuperNode

Next you will have to register PastelID in the blockchain. That requires some available funds (slightly more then 1000PSL - we recommend at least 2000PSL) in the SuperNode wallet.

Check balance:

If that returns 0 or anything less then 200PSL, you will need to generate new address and send some coins to it from your other walet.

Remember, or better write down your address (<ADDRESS>)

Send some coins to that address from another host with balance

Wait until coins get available, checking periodically with getbalance command.

4. Register pastelid

After funds get avaialiable, run the following command

Replace the placeholders with the appropriate values!

Check status again:

This time it should be something like that:

You can exit your SSH session to HOT node after that. You SuperNodes is running!

III. Common tasks

1. Set up the SuperNode as a service

NOTE: All commands should be executed on the COLD node!

To simplify management of SuperNode it is recommended to set it up as systems service. Follow the steps to do that

1. Stop SuperNode

Before setting up SuperNode's applications as systemd services, you first need to stop them

2. Set as service

3. Start SN again, this time as services

TIP: Instead of this command, you can add flag --start to the previous one