markdown structure formatting, rendered pages unchanged
This commit is contained in:
Erin Rivas
@@ -1,4 +1,4 @@
|
||||
{
|
||||
"label": "The Protocol",
|
||||
"position":6
|
||||
"position": 6
|
||||
}
|
||||
|
||||
@@ -1,32 +1,45 @@
|
||||
---
|
||||
sidebar_position: 2
|
||||
---
|
||||
|
||||
# Encryption in Jackal Protocol
|
||||
|
||||
The Jackal Protocol utilizes encryption techniques to ensure the privacy and security of user data. The two primary encryption models within the protocol are file encryption and file-entry encryption. File encryption secures the files themselves, while file-entry encryption focuses on securing the file entries on the blockchain.
|
||||
The Jackal Protocol utilizes encryption techniques to ensure the privacy and security of user data. The two primary
|
||||
encryption models within the protocol are file encryption and file-entry encryption. File encryption secures the files
|
||||
themselves, while file-entry encryption focuses on securing the file entries on the blockchain.
|
||||
|
||||
## File Encryption
|
||||
|
||||
File encryption is essential for protecting the data stored on storage providers within the Jackal Protocol. Before transferring files to storage providers, the user's client encrypts the files using a randomly generated symmetric key. The Advanced Encryption Standard (AES-256) is used for this encryption process, resulting in a securely encrypted file.
|
||||
File encryption is essential for protecting the data stored on storage providers within the Jackal Protocol. Before
|
||||
transferring files to storage providers, the user's client encrypts the files using a randomly generated symmetric key.
|
||||
The Advanced Encryption Standard (AES-256) is used for this encryption process, resulting in a securely encrypted file.
|
||||
|
||||
|
||||
|
||||
The symmetric key's secure storage is equally crucial, as exposing it would compromise the file's encryption. The Jackal Chain's File Tree Module serves as a safe and immutable location for storing the encrypted symmetric key alongside the file's location.
|
||||
The symmetric key's secure storage is equally crucial, as exposing it would compromise the file's encryption. The Jackal
|
||||
Chain's File Tree Module serves as a safe and immutable location for storing the encrypted symmetric key alongside the
|
||||
file's location.
|
||||
|
||||
## Integrated Encryption Scheme
|
||||
|
||||
The protocol uses an Integrated Encryption Scheme based on AES and the Elliptic Curve cryptography, which generates Bech32 addresses for secure key storage.
|
||||
The protocol uses an Integrated Encryption Scheme based on AES and the Elliptic Curve cryptography, which generates
|
||||
Bech32 addresses for secure key storage.
|
||||
|
||||
|
||||
|
||||
To securely store the symmetric key, the protocol encrypts it with the user's public key. This process ensures that only the user with the corresponding private key can decrypt the symmetric key.
|
||||
To securely store the symmetric key, the protocol encrypts it with the user's public key. This process ensures that only
|
||||
the user with the corresponding private key can decrypt the symmetric key.
|
||||
|
||||
|
||||
|
||||
When decrypting a file, the user's private key is used to decrypt the symmetric key. Once the symmetric key is retrieved, it can be used to decrypt the file stored on the storage provider, resulting in the original uploaded file.
|
||||
When decrypting a file, the user's private key is used to decrypt the symmetric key. Once the symmetric key is
|
||||
retrieved, it can be used to decrypt the file stored on the storage provider, resulting in the original uploaded file.
|
||||
|
||||
## File Sharing and Access
|
||||
|
||||
To share files with other users, the protocol first decrypts the symmetric key from the chain, then retrieves the external user's public key from the chain, and encrypts the symmetric key with the external user's public key. By appending the newly encrypted symmetric key to the file entry, the external user gains access to the file.
|
||||
To share files with other users, the protocol first decrypts the symmetric key from the chain, then retrieves the
|
||||
external user's public key from the chain, and encrypts the symmetric key with the external user's public key. By
|
||||
appending the newly encrypted symmetric key to the file entry, the external user gains access to the file.
|
||||
|
||||
By leveraging encryption techniques for both files and file entries, the Jackal Protocol ensures the privacy, security, and integrity of user data throughout the storage and sharing processes.
|
||||
By leveraging encryption techniques for both files and file entries, the Jackal Protocol ensures the privacy, security,
|
||||
and integrity of user data throughout the storage and sharing processes.
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
{
|
||||
"label": "Blockchain Modules",
|
||||
"position":1
|
||||
"position": 1
|
||||
}
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
sidebar_position: 7
|
||||
---
|
||||
|
||||
# dsig Module
|
||||
|
||||
## Coming Soon
|
||||
|
||||
@@ -1,24 +1,52 @@
|
||||
---
|
||||
sidebar_position: 8
|
||||
---
|
||||
|
||||
# Filetree Module
|
||||
|
||||
## Overview
|
||||
The Jackal Filetree module is responsible for organizing and managing user files in a secure and user-friendly way. When a user uploads a file using the Storage module, the file is only accessible from the File ID (FID), which can be challenging to remember for every file uploaded to Jackal. Additionally, every single upload would be required to be public, or the user would need to keep track of every symmetric key used to encrypt the files and manually map them to the FIDs. To address this issue, the File Tree module implements a tree structure to store each file as an entry in the tree. Organizing this structure is also trivial as we can assign children to pseudo files that we call folders. Finally, to keep track of encryption keys, the protocol maps every file to its respective key, emphasizing the security and privacy posture that the File Tree module enables.
|
||||
|
||||
The Jackal Filetree module is responsible for organizing and managing user files in a secure and user-friendly way. When
|
||||
a user uploads a file using the Storage module, the file is only accessible from the File ID (FID), which can be
|
||||
challenging to remember for every file uploaded to Jackal. Additionally, every single upload would be required to be
|
||||
public, or the user would need to keep track of every symmetric key used to encrypt the files and manually map them to
|
||||
the FIDs. To address this issue, the File Tree module implements a tree structure to store each file as an entry in the
|
||||
tree. Organizing this structure is also trivial as we can assign children to pseudo files that we call folders. Finally,
|
||||
to keep track of encryption keys, the protocol maps every file to its respective key, emphasizing the security and
|
||||
privacy posture that the File Tree module enables.
|
||||
|
||||
|
||||
|
||||
|
||||
## Folder Abstraction
|
||||
These, of course, are all abstractions of what's actually under the hood. The File Tree module doesn't actually handle any of the folder logic; the system believes it is storing files that act as metadata stores, which then update to reflect changes in folders. This gives the user experience the feeling that folders and files are separate entities in the tree, but in reality, they are identical.
|
||||
|
||||
These, of course, are all abstractions of what's actually under the hood. The File Tree module doesn't actually handle
|
||||
any of the folder logic; the system believes it is storing files that act as metadata stores, which then update to
|
||||
reflect changes in folders. This gives the user experience the feeling that folders and files are separate entities in
|
||||
the tree, but in reality, they are identical.
|
||||
|
||||
## File Entry Structure
|
||||
Storing file entries on-chain is a challenge since the chain itself is public. This requires the use of client-side encryption before uploading data to the chain itself. The main component of a file is location (Address), allowing users to query the rest of the data from the file. You can think of the location as a key in a traditional key-value store or a path in bucket-based storage. The address is hashed using SHA256 to ensure it is impossible to retrieve the plain-text representation of the file name while still being able to query the file using its given name.
|
||||
|
||||
Storing file entries on-chain is a challenge since the chain itself is public. This requires the use of client-side
|
||||
encryption before uploading data to the chain itself. The main component of a file is location (Address), allowing users
|
||||
to query the rest of the data from the file. You can think of the location as a key in a traditional key-value store or
|
||||
a path in bucket-based storage. The address is hashed using SHA256 to ensure it is impossible to retrieve the plain-text
|
||||
representation of the file name while still being able to query the file using its given name.
|
||||
|
||||
|
||||
|
||||
The second most important data point in a file is the content of the file. This field is extremely versatile as it can store any string. Traditionally this is used to store a JSON list of FIDs to point to a file on the Storage Module; however, the protocol can also theoretically use it to store short bits of text like encrypted passwords for a private password manager. The owner tag is a hashed version of the owner, hiding what address owns each file. This field can be changed to reflect the transferral of ownership. When making changes to the file such as deletion, movement, or adding/removing viewers/editors, the owner field is consulted to determine permissions. The same applies to edit access; editors can update the contents but nothing else.
|
||||
The second most important data point in a file is the content of the file. This field is extremely versatile as it can
|
||||
store any string. Traditionally this is used to store a JSON list of FIDs to point to a file on the Storage Module;
|
||||
however, the protocol can also theoretically use it to store short bits of text like encrypted passwords for a private
|
||||
password manager. The owner tag is a hashed version of the owner, hiding what address owns each file. This field can be
|
||||
changed to reflect the transferral of ownership. When making changes to the file such as deletion, movement, or
|
||||
adding/removing viewers/editors, the owner field is consulted to determine permissions. The same applies to edit access;
|
||||
editors can update the contents but nothing else.
|
||||
|
||||
## Encrypted Viewing Access
|
||||
|
||||
For users to view files, they need access to the symmetric keys used to encrypt the files. To do this, the protocol has a map of hashed addresses with each user's respective version of the symmetric key encrypted with that address's corresponding public key. The protocol can then store that map in the file entry to act as an encryption key discovery layer. The addresses in this viewing list are only able to access files and decrypt the data in their client; they have no privileges over the modification of the file entry in any way. This approach ensures that the File Tree module maintains a strong security and privacy posture for user data.
|
||||
For users to view files, they need access to the symmetric keys used to encrypt the files. To do this, the protocol has
|
||||
a map of hashed addresses with each user's respective version of the symmetric key encrypted with that address's
|
||||
corresponding public key. The protocol can then store that map in the file entry to act as an encryption key discovery
|
||||
layer. The addresses in this viewing list are only able to access files and decrypt the data in their client; they have
|
||||
no privileges over the modification of the file entry in any way. This approach ensures that the File Tree module
|
||||
maintains a strong security and privacy posture for user data.
|
||||
|
||||
@@ -4,7 +4,8 @@ sidebar_position: 2
|
||||
|
||||
# JKLmint Module
|
||||
|
||||
The `jklmint` module is responsible for the management of the native JKL token within the Jackal Protocol. This module handles the issuance, distribution, and inflation of JKL tokens, ensuring a stable and secure token economy.
|
||||
The `jklmint` module is responsible for the management of the native JKL token within the Jackal Protocol. This module
|
||||
handles the issuance, distribution, and inflation of JKL tokens, ensuring a stable and secure token economy.
|
||||
|
||||
## Overview
|
||||
|
||||
|
||||
@@ -1,9 +1,12 @@
|
||||
---
|
||||
sidebar_position: 3
|
||||
---
|
||||
|
||||
# LP Module (Coming Soon)
|
||||
|
||||
The `lp` (Liquidity Provision) module is a vital part of the Jackal Protocol, enabling the creation and management of liquidity pools for trading and swapping tokens. This module provides a decentralized solution for users to contribute liquidity to the ecosystem and earn rewards in return.
|
||||
The `lp` (Liquidity Provision) module is a vital part of the Jackal Protocol, enabling the creation and management of
|
||||
liquidity pools for trading and swapping tokens. This module provides a decentralized solution for users to contribute
|
||||
liquidity to the ecosystem and earn rewards in return.
|
||||
|
||||
## Overview
|
||||
|
||||
@@ -14,4 +17,5 @@ The `lp` module manages the following aspects of liquidity pools:
|
||||
3. **Token Swaps**: Enables decentralized trading and swapping of tokens within the liquidity pools.
|
||||
4. **Rewards**: Distributes rewards to liquidity providers proportionate to their contribution.
|
||||
|
||||
For a more detailed guide on the 'lp' module, please refer to the [module documentation](https://github.com/JackalLabs/canine-chain/blob/master/x/lp/README.md) on GitHub.
|
||||
For a more detailed guide on the 'lp' module, please refer to
|
||||
the [module documentation](https://github.com/JackalLabs/canine-chain/blob/master/x/lp/README.md) on GitHub.
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
---
|
||||
# Module Overview
|
||||
|
||||
# Module Overview
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,9 +1,13 @@
|
||||
---
|
||||
sidebar_position: 4
|
||||
---
|
||||
|
||||
# Name Service Module
|
||||
|
||||
The `rns` (Reverse Name Service) module is an essential component of the Jackal Protocol, providing a user-friendly naming system for blockchain addresses. The RNS module simplifies the process of interacting with complex addresses by mapping them to human-readable names. This module allows users to transfer tokens and permissions to files/folders stored on the Jackal Protocol using human readable names.
|
||||
The `rns` (Reverse Name Service) module is an essential component of the Jackal Protocol, providing a user-friendly
|
||||
naming system for blockchain addresses. The RNS module simplifies the process of interacting with complex addresses by
|
||||
mapping them to human-readable names. This module allows users to transfer tokens and permissions to files/folders
|
||||
stored on the Jackal Protocol using human readable names.
|
||||
|
||||
## Overview
|
||||
|
||||
@@ -15,4 +19,5 @@ The `rns` module manages the following aspects of the Reverse Name Service:
|
||||
4. **Name Sales**: Enables users to buy and sell RNS names through the RNS Marketplace.
|
||||
5. **Name Transfers**: Enables users to transfer RNS names.
|
||||
|
||||
For a more detailed guide on integrating the rns module into your application, please refer to the [module documentation](https://github.com/JackalLabs/canine-chain/blob/master/x/README.md) on GitHub.
|
||||
For a more detailed guide on integrating the rns module into your application, please refer to
|
||||
the [module documentation](https://github.com/JackalLabs/canine-chain/blob/master/x/README.md) on GitHub.
|
||||
|
||||
@@ -4,28 +4,46 @@ sidebar_position: 6
|
||||
|
||||
# Storage Module
|
||||
|
||||
The Jackal Protocol incorporates two crucial algorithms for decentralized storage: Jackal Proof-of-Persistence (JPOP) and Internal Detection Of Loss (IDOL) protocols. This document provides an overview of these algorithms, their functionalities, and their interaction with users and Storage Providers.
|
||||
The Jackal Protocol incorporates two crucial algorithms for decentralized storage: Jackal Proof-of-Persistence (JPOP)
|
||||
and Internal Detection Of Loss (IDOL) protocols. This document provides an overview of these algorithms, their
|
||||
functionalities, and their interaction with users and Storage Providers.
|
||||
|
||||
## Jackal Proof-of-Persistence (JPOP)
|
||||
|
||||
JPOP is a Proof-of-Storage algorithm that governs the relationship between the storage provider and the user. It operates through a series of contracts containing the Merkle Tree root hash of the file and information required to prove ownership. Storage Providers are responsible for posting Merkle Proofs within a challenge window determined by the blockchain.
|
||||
JPOP is a Proof-of-Storage algorithm that governs the relationship between the storage provider and the user. It
|
||||
operates through a series of contracts containing the Merkle Tree root hash of the file and information required to
|
||||
prove ownership. Storage Providers are responsible for posting Merkle Proofs within a challenge window determined by the
|
||||
blockchain.
|
||||
|
||||
The challenge windows require miners to post the raw data chunk and the required Merkle Hashes to prove the data belongs to the Merkle Root stored on the contract. The challenge indexes are chosen at random by the blockchain using a block-hash-based random number generator paired with a random data oracle.
|
||||
The challenge windows require miners to post the raw data chunk and the required Merkle Hashes to prove the data belongs
|
||||
to the Merkle Root stored on the contract. The challenge indexes are chosen at random by the blockchain using a
|
||||
block-hash-based random number generator paired with a random data oracle.
|
||||
|
||||
## Internal Detection Of Loss (IDOL) Protocol
|
||||
|
||||
The IDOL protocol ensures that data remains available and accessible. When a Storage Provider successfully posts a Merkle Proof within the challenge window, and Validators verify the data, the Storage Provider is rewarded. The rewards are proportional to the file size associated with the contract relative to other active contracts on the network.
|
||||
The IDOL protocol ensures that data remains available and accessible. When a Storage Provider successfully posts a
|
||||
Merkle Proof within the challenge window, and Validators verify the data, the Storage Provider is rewarded. The rewards
|
||||
are proportional to the file size associated with the contract relative to other active contracts on the network.
|
||||
|
||||
If a Storage Provider fails to provide a valid proof within the allotted timeframe, the contract is marked with a missed proof. After a certain number of missed proofs, the contract is burned, and the user is alerted the next time they query the contract. Storage Providers receive penalties for every contract burned due to missed proofs, which remain on their record for an adjustable period.
|
||||
If a Storage Provider fails to provide a valid proof within the allotted timeframe, the contract is marked with a missed
|
||||
proof. After a certain number of missed proofs, the contract is burned, and the user is alerted the next time they query
|
||||
the contract. Storage Providers receive penalties for every contract burned due to missed proofs, which remain on their
|
||||
record for an adjustable period.
|
||||
|
||||
The IDOL protocol comes into play when contracts with missed proofs are moved to a new list where they can be claimed by other providers. The new provider downloads the file from one of the two online providers storing the same file, resumes the contract's proof action, and restores redundancy to 3x.
|
||||
The IDOL protocol comes into play when contracts with missed proofs are moved to a new list where they can be claimed by
|
||||
other providers. The new provider downloads the file from one of the two online providers storing the same file, resumes
|
||||
the contract's proof action, and restores redundancy to 3x.
|
||||
|
||||
## Interaction Outline
|
||||
|
||||
1. A user sends a file to an available Storage Provider. A list of Storage Providers can be found on the blockchain, and miners can deny any incoming request if they do not want to store new files.
|
||||
2. After receiving the entire file, the Storage Provider keeps the file in memory and posts a contract to the blockchain.
|
||||
3. If the contract is not signed by the sender within a certain number of blocks (configurable by the Storage Provider), the file is removed from memory, and the contract is burned.
|
||||
4. If the contract is signed by the user within the given number of blocks, the file is committed to the Storage Provider's hard storage, and the challenge windows start being created for the now active contract.
|
||||
1. A user sends a file to an available Storage Provider. A list of Storage Providers can be found on the blockchain, and
|
||||
miners can deny any incoming request if they do not want to store new files.
|
||||
2. After receiving the entire file, the Storage Provider keeps the file in memory and posts a contract to the
|
||||
blockchain.
|
||||
3. If the contract is not signed by the sender within a certain number of blocks (configurable by the Storage Provider),
|
||||
the file is removed from memory, and the contract is burned.
|
||||
4. If the contract is signed by the user within the given number of blocks, the file is committed to the Storage
|
||||
Provider's hard storage, and the challenge windows start being created for the now active contract.
|
||||
|
||||
## Client Query Commands
|
||||
|
||||
@@ -61,6 +79,9 @@ The transaction commands allow users to interact with the storage module. Exampl
|
||||
- `cancel-contract`
|
||||
- `upgrade-storage`
|
||||
|
||||
By implementing the JPOP and IDOL protocols, the Jackal Protocol ensures secure, efficient, and reliable decentralized storage management. These protocols, along with the provided client query commands and transactions, enable users and Storage Providers to interact with the Jackal storage ecosystem seamlessly.
|
||||
By implementing the JPOP and IDOL protocols, the Jackal Protocol ensures secure, efficient, and reliable decentralized
|
||||
storage management. These protocols, along with the provided client query commands and transactions, enable users and
|
||||
Storage Providers to interact with the Jackal storage ecosystem seamlessly.
|
||||
|
||||
Please refer to the respective command documentation for detailed usage and parameters. The Jackal Protocol continues to evolve, and as new features are added, updates to this documentation will be provided accordingly.
|
||||
Please refer to the respective command documentation for detailed usage and parameters. The Jackal Protocol continues to
|
||||
evolve, and as new features are added, updates to this documentation will be provided accordingly.
|
||||
|
||||
@@ -4,15 +4,19 @@ sidebar_position: 5
|
||||
|
||||
# WASM Module
|
||||
|
||||
The `wasm` module in the Jackal Protocol incorporates the CosmWasm smart contracting platform, which is designed specifically for the Cosmos Ecosystem. This module provides a secure and efficient environment for executing WebAssembly (WASM) smart contracts on the Jackal Protocol.
|
||||
The `wasm` module in the Jackal Protocol incorporates the CosmWasm smart contracting platform, which is designed
|
||||
specifically for the Cosmos Ecosystem. This module provides a secure and efficient environment for executing
|
||||
WebAssembly (WASM) smart contracts on the Jackal Protocol.
|
||||
|
||||
## Overview
|
||||
|
||||
The `wasm` module manages the following aspects of the CosmWasm platform:
|
||||
|
||||
1. **Smart Contract Deployment**: Allows developers to deploy smart contracts written in Rust or other languages that compile to WASM.
|
||||
1. **Smart Contract Deployment**: Allows developers to deploy smart contracts written in Rust or other languages that
|
||||
compile to WASM.
|
||||
2. **Smart Contract Execution**: Facilitates the execution of smart contract functions on the blockchain.
|
||||
3. **Smart Contract Interaction**: Enables users and other smart contracts to interact with deployed smart contracts.
|
||||
|
||||
For a more detailed guide on integrating the wasm module into your application, please refer to the [Jackal Protocol GitHub](https://github.com/JackalLabs/canine-chain/blob/master/x/README.md).
|
||||
For a more detailed guide on integrating the wasm module into your application, please refer to
|
||||
the [Jackal Protocol GitHub](https://github.com/JackalLabs/canine-chain/blob/master/x/README.md).
|
||||
|
||||
|
||||
+20
-4
@@ -5,15 +5,26 @@ sidebar_position: 1
|
||||
# Jackal Proof-of-Persistence Documentation
|
||||
|
||||
## Overview
|
||||
Jackal Storage is powered by a Proof-of-Storage algorithm called Proof-of-Persistence (JPOP). JPOP is designed to ensure the secure and persistent storage of user data through a series of contracts formed between the storage provider and the user. These contracts contain the Merkle Tree root hash of the file and the information required to prove ownership of the file. In this documentation, we'll explain the core components and processes involved in the Jackal Proof-of-Persistence.
|
||||
|
||||
Jackal Storage is powered by a Proof-of-Storage algorithm called Proof-of-Persistence (JPOP). JPOP is designed to ensure
|
||||
the secure and persistent storage of user data through a series of contracts formed between the storage provider and the
|
||||
user. These contracts contain the Merkle Tree root hash of the file and the information required to prove ownership of
|
||||
the file. In this documentation, we'll explain the core components and processes involved in the Jackal
|
||||
Proof-of-Persistence.
|
||||
|
||||
## Building the Trees
|
||||
|
||||
Merkle Trees are a core component of the JPOP mechanism, thus, it is important to outline how these trees are used to create efficient and trustworthy proofs. When saving a file for the first time, providers split each file into many 1kb chunks. Providers must also hash the entire file to create a folder to house every chunk, this is displayed by the following diagram.
|
||||
Merkle Trees are a core component of the JPOP mechanism, thus, it is important to outline how these trees are used to
|
||||
create efficient and trustworthy proofs. When saving a file for the first time, providers split each file into many 1kb
|
||||
chunks. Providers must also hash the entire file to create a folder to house every chunk, this is displayed by the
|
||||
following diagram.
|
||||
|
||||
|
||||
|
||||
These chunks are used as leaves on the Merkle Tree defining each storage contract. Immediately after saving a file to disk, the storage provider builds a tree using each chunk. To create this tree, each chunk is hashed into a respective Hashed Chunk. These chunks are then recursively paired together and hashed until a single root node is created. This is called the Merkle Root, the only piece of data relative to a file that is saved directly on the blockchain itself.
|
||||
These chunks are used as leaves on the Merkle Tree defining each storage contract. Immediately after saving a file to
|
||||
disk, the storage provider builds a tree using each chunk. To create this tree, each chunk is hashed into a respective
|
||||
Hashed Chunk. These chunks are then recursively paired together and hashed until a single root node is created. This is
|
||||
called the Merkle Root, the only piece of data relative to a file that is saved directly on the blockchain itself.
|
||||
|
||||
|
||||
|
||||
@@ -21,6 +32,11 @@ In the diagram above, displays how each file is hashed together to create a sing
|
||||
|
||||
## Proving Data Availability
|
||||
|
||||
These nodes are essential as they only require the nodes below them to prove they are part of the tree. This means that we can create a proof claiming a single chunk belongs to the file using the Merkle Root saved on the chain. In the following diagram, we can see that only the blue nodes are required to build a successful proof. The green nodes represent information that we can generate given the blue nodes. Finally, we can compare the root generated from the proof to the root saved on the chain and determine if the chunk does belong to the contract we are proving. This results in small message sizes due to not needing to send the entire file every proof.
|
||||
These nodes are essential as they only require the nodes below them to prove they are part of the tree. This means that
|
||||
we can create a proof claiming a single chunk belongs to the file using the Merkle Root saved on the chain. In the
|
||||
following diagram, we can see that only the blue nodes are required to build a successful proof. The green nodes
|
||||
represent information that we can generate given the blue nodes. Finally, we can compare the root generated from the
|
||||
proof to the root saved on the chain and determine if the chunk does belong to the contract we are proving. This results
|
||||
in small message sizes due to not needing to send the entire file every proof.
|
||||
|
||||
|
||||
|
||||
+25
-7
@@ -1,40 +1,58 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
---
|
||||
|
||||
# JKL Token
|
||||
|
||||
## Overview
|
||||
The JKL token is an inflationary token that powers the Jackal Protocol. It has numerous use cases within the ecosystem, ensuring its utility and importance. In this documentation, we will outline the main use cases of the JKL token and explain its role in the Jackal Protocol ecosystem.
|
||||
|
||||
The JKL token is an inflationary token that powers the Jackal Protocol. It has numerous use cases within the ecosystem,
|
||||
ensuring its utility and importance. In this documentation, we will outline the main use cases of the JKL token and
|
||||
explain its role in the Jackal Protocol ecosystem.
|
||||
|
||||
## Use Cases
|
||||
|
||||
### dApps
|
||||
Applications built leveraging the Jackal Protocol, such as Jackal Storage and the RNS Marketplace, may choose to include the JKL token to expand its utility.
|
||||
|
||||
Applications built leveraging the Jackal Protocol, such as Jackal Storage and the RNS Marketplace, may choose to include
|
||||
the JKL token to expand its utility.
|
||||
|
||||
### Securing the Network
|
||||
As the Jackal Protocol is a Proof-of-Stake (PoS) Cosmos L1 blockchain, JKL can be delegated to validators to secure the network and earn JKL rewards. Otherwise known as staking or bonded tokens.
|
||||
|
||||
As the Jackal Protocol is a Proof-of-Stake (PoS) Cosmos L1 blockchain, JKL can be delegated to validators to secure the
|
||||
network and earn JKL rewards. Otherwise known as staking or bonded tokens.
|
||||
|
||||
### Transaction Fees
|
||||
Transactions on the Jackal Protocol must be paid for using JKL. As the protocol is PoS, the cost of transactions is inexpensive.
|
||||
|
||||
Transactions on the Jackal Protocol must be paid for using JKL. As the protocol is PoS, the cost of transactions is
|
||||
inexpensive.
|
||||
|
||||
### Governance
|
||||
Staked tokens grant on-chain governance participation within the Jackal Protocol to vote on text, software, spend, and other governance proposals.
|
||||
|
||||
Staked tokens grant on-chain governance participation within the Jackal Protocol to vote on text, software, spend, and
|
||||
other governance proposals.
|
||||
|
||||
### Collateral
|
||||
|
||||
The JKL token can act as collateral for validators, storage providers, and other smart contract use cases.
|
||||
|
||||
### Liquidity Provision
|
||||
|
||||
JKL can be allocated into a liquidity pool to earn rewards.
|
||||
|
||||
## Unique JKL Token Utility for Users and Storage Providers
|
||||
|
||||
### Users
|
||||
|
||||
Users seeking storage solutions can leverage JKL tokens to pay for the storage services provided by storage providers within the Jackal Protocol. By utilizing JKL tokens as a medium of exchange, users can access a decentralized, secure, and censorship-resistant storage infrastructure.
|
||||
Users seeking storage solutions can leverage JKL tokens to pay for the storage services provided by storage providers
|
||||
within the Jackal Protocol. By utilizing JKL tokens as a medium of exchange, users can access a decentralized, secure,
|
||||
and censorship-resistant storage infrastructure.
|
||||
|
||||
### Storage Providers
|
||||
|
||||
Storage providers are incentivized to offer storage space and maintain a high level of service by earning JKL tokens. By receiving JKL tokens as payment for their services, storage providers can cover the costs of infrastructure, hardware, and bandwidth while potentially profiting from their participation in the ecosystem.
|
||||
Storage providers are incentivized to offer storage space and maintain a high level of service by earning JKL tokens. By
|
||||
receiving JKL tokens as payment for their services, storage providers can cover the costs of infrastructure, hardware,
|
||||
and bandwidth while potentially profiting from their participation in the ecosystem.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,9 +1,15 @@
|
||||
---
|
||||
sidebar_position: 5
|
||||
---
|
||||
|
||||
# Validators
|
||||
The Jackal Validators are secure web servers, dedicated machines that participate in the consensus protocol by broadcasting cryptographic signatures, or votes, to agree upon the next block. Voting power is determined by the amount of staking tokens delegated by non-validators and bonded as collateral to earn a reward. These non-validators, or delegators, incur the risk of getting punished (slashed) if the delegate validator gets hacked or violates the protocol.
|
||||
|
||||
To set up a validator and become a contributing part of the network, read the installation instructions [here](/docs/nodes/nodes/installation)
|
||||
The Jackal Validators are secure web servers, dedicated machines that participate in the consensus protocol by
|
||||
broadcasting cryptographic signatures, or votes, to agree upon the next block. Voting power is determined by the amount
|
||||
of staking tokens delegated by non-validators and bonded as collateral to earn a reward. These non-validators, or
|
||||
delegators, incur the risk of getting punished (slashed) if the delegate validator gets hacked or violates the protocol.
|
||||
|
||||
To set up a validator and become a contributing part of the network, read the installation
|
||||
instructions [here](/docs/nodes/nodes/installation)
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user