Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 20 additions & 18 deletions docs/cli-tools/txs/validator.md
Original file line number Diff line number Diff line change
@@ -1,26 +1,24 @@
---
sidebar_position: 3
description: 'Control a Validator'
description: "Control a Validator"
---

# Txs - Validator



## Description
The `libra txs validator` subcommand includes a set of subcommands tailored for validator operations. These commands facilitate actions like managing validator-specific transactions such as bids for joining the validator set.

The `libra txs validator` subcommand includes a set of subcommands tailored for validator operations. These commands facilitate actions like managing validator-specific transactions such as bids for joining the validator set.

## Validator Transactions
## Validator Transactions

### Proof of Fee (POF) Operations

OL Network uses the [Libra Framework](https://github.com/0LNetworkCommunity/libra-framework) that uses an experimental algorithm called Proof of Fee(PoF) to determine the validator selection. Libra Framework's consensus mechanism stands apart from the more commonly known frameworks like Proof of Stake (PoS), Delegated Proof of Stake (DPoS), and Proof of Work (PoW), which are prevalent in many other blockchain networks. Instead of following these established paradigms, 0L Network employs a unique auction-based system for validator selection.

In this system, validators are required to submit bids as part of a competitive auction process. The number of available seats for validators is dynamic, and these seats are allocated based on the bid amounts. The bids are evaluated in descending order, and the highest bidders are granted validator status until all the seats are filled. A critical aspect of this mechanism is that all participating validators, regardless of their individual bid amounts, will eventually pay the same fee — equal to the lowest accepted bid in the auction.

For a deeper understanding of this distinctive approach, you can delve into the conceptual and operational intricacies detailed in the following papers: [Part 1](https://0l.network/2022/10/15/proof-of-fee-part-1/) & [Part 2](https://0l.network/2022/10/20/proof-of-fee-part-2-a-proposal/)


- **Function**: Manages bids for joining the validator set.
- **Syntax**: `libra txs validator pof --bid-pct <BID_PERCENTAGE> --expiry <EXPIRY>`
- **Parameters**:
Expand All @@ -32,6 +30,7 @@ For a deeper understanding of this distinctive approach, you can delve into the
```

### Register Validator

> Make sure you have your config at `~/.libra/libra.yaml` with `libra config init`

- **Function**: Registers a new validator on the network.
Expand All @@ -44,6 +43,7 @@ For a deeper understanding of this distinctive approach, you can delve into the
```

### Update Network and Fullnode Addresses

Within the Libra framework, the validator's operational settings are managed through a configuration file named operator.yaml, typically located in the ~/.libra/ directory. This file encapsulates key configuration details for the validator. To update the validator's operational parameters, one can modify this configuration file and then submit a corresponding transaction to the Libra blockchain. This transaction ensures that the changes in the configuration file are acknowledged and implemented by the network.

For your reference, the structure and content of the operator.yaml file are outlined below. It's important to note that the actual configuration may vary based on specific network requirements and validator setups:
Expand Down Expand Up @@ -73,34 +73,36 @@ full_node_host: ~
```

### Manage Vouching Operations

In the Libra framework, the concept of "vouching" is implemented as a means to establish and assess trust among participants. Primarily applied in the context of validators, this mechanism requires each validator to secure vouches from two existing validators. These endorsing validators must belong to distinct ancestry trees; in other words, they should not be part of the same lineage or hierarchical chain of account creation.

Additionally, the vouching system is governed by certain predefined rules. Each vouch has a finite lifespan, set to expire after 90 epochs. There is also a financial aspect to vouching: obtaining a vouch incurs a cost of 1000 microlibra. This amount is not merely a fee but is burned, signifying a tangible commitment and adding a layer of economic deterrence against frivolous or inauthentic vouching.

- **Function**: Manages vouching for or revoking a vouch for other entities in the network.
- **Syntax**: `libra txs validator vouch --vouch-for <VALIDATOR_ADDRESS> [--revoke]`
- **Parameters**:
- **Parameters**:
- `vouch-for`: The account of the validator you would like to vouch for or remove your vouch for
- **Example**:
- **Vouch for a validator**
```
libra txs validator vouch --vouch-for 0xC7394B8AF7BC3BDB9258C53DFFDA7F2B
```
```
libra txs validator vouch --vouch-for 0xC7394B8AF7BC3BDB9258C53DFFDA7F2B
```
- **Remove a vouch for a validator**
```
libra txs validator vouch --vouch-for 0xC7394B8AF7BC3BDB9258C53DFFDA7F2B --revoke
```
```
libra txs validator vouch --vouch-for 0xC7394B8AF7BC3BDB9258C53DFFDA7F2B --revoke
```

### Manage Jail Operations
In the Libra framework, validators failing to meet consensus rules, especially in performance, are "jailed" and removed from the validator set. They can only rejoin once a validator who previously vouched for them submits an "unjail" transaction. This jailing process, part of the Vouch system, impacts the reputations and responsibilities of both the jailed validator and their voucher, with consequences extending recursively to others in the vouching chain. Additionally, the voucher risks losing financial deposits, adding a significant stake to the maintenance of network standards and performance.

In the Libra framework, validators who fail to meet consensus rules, particularly in terms of performance, are 'jailed' and removed from the validator set. They can only rejoin if a validator from the active set, who previously vouched for them, submits an 'unjail' transaction. This jailing process, part of the Vouch system, affects the reputations and responsibilities of both the jailed validator and their voucher, with consequences extending recursively to others in the vouching chain. Additionally, the voucher risks losing financial deposits, which adds significant stakes to maintaining network standards and performance.

- **Function**: Manages Jail functions within the network.
- **Syntax**: `libra txs validator jail --unjail-acct <UNJAIL_ACCT>`
- **Parameters**:
- **Parameters**:
- `unjail-acct`: The account of the validator a voucher would like to unjail
- **Example**:
```
libra txs validator jail --unjail-acct 0xC7394B8AF7BC3BDB9258C53DFFDA7F2B
```
```
libra txs validator jail --unjail-acct 0xC7394B8AF7BC3BDB9258C53DFFDA7F2B
```

---