diff --git a/docs_copy/about/_category_.json b/docs/about/_category_.json similarity index 100% rename from docs_copy/about/_category_.json rename to docs/about/_category_.json diff --git a/docs_copy/about/engineering_strategy.todo b/docs/about/engineering_strategy.todo similarity index 100% rename from docs_copy/about/engineering_strategy.todo rename to docs/about/engineering_strategy.todo diff --git a/docs_copy/about/getting_started.todo b/docs/about/getting_started.todo similarity index 100% rename from docs_copy/about/getting_started.todo rename to docs/about/getting_started.todo diff --git a/docs_copy/about/historical_tech_stack.todo b/docs/about/historical_tech_stack.todo similarity index 100% rename from docs_copy/about/historical_tech_stack.todo rename to docs/about/historical_tech_stack.todo diff --git a/docs_copy/archive/_category_.json b/docs/archive/_category_.json similarity index 100% rename from docs_copy/archive/_category_.json rename to docs/archive/_category_.json diff --git a/docs_copy/archive/announcements/news/carpe_beta_launched.md b/docs/archive/announcements/news/carpe_beta_launched.md similarity index 100% rename from docs_copy/archive/announcements/news/carpe_beta_launched.md rename to docs/archive/announcements/news/carpe_beta_launched.md diff --git a/docs_copy/archive/announcements/news/carpe_goes_multilingual.md b/docs/archive/announcements/news/carpe_goes_multilingual.md similarity index 100% rename from docs_copy/archive/announcements/news/carpe_goes_multilingual.md rename to docs/archive/announcements/news/carpe_goes_multilingual.md diff --git a/docs_copy/archive/announcements/news/new_milestones_for_carpe.md b/docs/archive/announcements/news/new_milestones_for_carpe.md similarity index 100% rename from docs_copy/archive/announcements/news/new_milestones_for_carpe.md rename to docs/archive/announcements/news/new_milestones_for_carpe.md diff --git a/docs_copy/archive/announcements/news/press_mysten.md b/docs/archive/announcements/news/press_mysten.md similarity index 100% rename from docs_copy/archive/announcements/news/press_mysten.md rename to docs/archive/announcements/news/press_mysten.md diff --git a/docs_copy/archive/canonical/future_proofing_the_economics_of_blockchains_pt_3.md b/docs/archive/canonical/future_proofing_the_economics_of_blockchains_pt_3.md similarity index 100% rename from docs_copy/archive/canonical/future_proofing_the_economics_of_blockchains_pt_3.md rename to docs/archive/canonical/future_proofing_the_economics_of_blockchains_pt_3.md diff --git a/docs_copy/archive/canonical/future_proofing_the_economics_of_blockchains_pts_1__2.md b/docs/archive/canonical/future_proofing_the_economics_of_blockchains_pts_1__2.md similarity index 100% rename from docs_copy/archive/canonical/future_proofing_the_economics_of_blockchains_pts_1__2.md rename to docs/archive/canonical/future_proofing_the_economics_of_blockchains_pts_1__2.md diff --git a/docs_copy/archive/canonical/libra_liberated.md b/docs/archive/canonical/libra_liberated.md similarity index 100% rename from docs_copy/archive/canonical/libra_liberated.md rename to docs/archive/canonical/libra_liberated.md diff --git a/docs_copy/archive/canonical/technical/delay_towers_pt_0.md b/docs/archive/canonical/technical/delay_towers_pt_0.md similarity index 100% rename from docs_copy/archive/canonical/technical/delay_towers_pt_0.md rename to docs/archive/canonical/technical/delay_towers_pt_0.md diff --git a/docs_copy/archive/canonical/technical/delay_towers_pt_1.md b/docs/archive/canonical/technical/delay_towers_pt_1.md similarity index 100% rename from docs_copy/archive/canonical/technical/delay_towers_pt_1.md rename to docs/archive/canonical/technical/delay_towers_pt_1.md diff --git a/docs_copy/archive/canonical/technical/delay_towers_pt_2.md b/docs/archive/canonical/technical/delay_towers_pt_2.md similarity index 100% rename from docs_copy/archive/canonical/technical/delay_towers_pt_2.md rename to docs/archive/canonical/technical/delay_towers_pt_2.md diff --git a/docs_copy/archive/canonical/technical/delay_towers_pt_3_implementation_on_bft.md b/docs/archive/canonical/technical/delay_towers_pt_3_implementation_on_bft.md similarity index 100% rename from docs_copy/archive/canonical/technical/delay_towers_pt_3_implementation_on_bft.md rename to docs/archive/canonical/technical/delay_towers_pt_3_implementation_on_bft.md diff --git a/docs_copy/archive/canonical/technical/proof_of_fee_part_1.md b/docs/archive/canonical/technical/proof_of_fee_part_1.md similarity index 100% rename from docs_copy/archive/canonical/technical/proof_of_fee_part_1.md rename to docs/archive/canonical/technical/proof_of_fee_part_1.md diff --git a/docs_copy/archive/canonical/technical/proof_of_fee_part_2.md b/docs/archive/canonical/technical/proof_of_fee_part_2.md similarity index 100% rename from docs_copy/archive/canonical/technical/proof_of_fee_part_2.md rename to docs/archive/canonical/technical/proof_of_fee_part_2.md diff --git a/docs_copy/archive/canonical/technical/research_report_decentralizing_permissioned_blockchain_with_delay_towers.md b/docs/archive/canonical/technical/research_report_decentralizing_permissioned_blockchain_with_delay_towers.md similarity index 100% rename from docs_copy/archive/canonical/technical/research_report_decentralizing_permissioned_blockchain_with_delay_towers.md rename to docs/archive/canonical/technical/research_report_decentralizing_permissioned_blockchain_with_delay_towers.md diff --git a/docs_copy/archive/community/community.todo b/docs/archive/community/community.todo similarity index 100% rename from docs_copy/archive/community/community.todo rename to docs/archive/community/community.todo diff --git a/docs_copy/archive/community/community_programs.todo b/docs/archive/community/community_programs.todo similarity index 100% rename from docs_copy/archive/community/community_programs.todo rename to docs/archive/community/community_programs.todo diff --git a/docs_copy/archive/community/economics.todo b/docs/archive/community/economics.todo similarity index 100% rename from docs_copy/archive/community/economics.todo rename to docs/archive/community/economics.todo diff --git a/docs_copy/archive/community/governance.todo b/docs/archive/community/governance.todo similarity index 100% rename from docs_copy/archive/community/governance.todo rename to docs/archive/community/governance.todo diff --git a/docs_copy/archive/community/hustle_karma.todo b/docs/archive/community/hustle_karma.todo similarity index 100% rename from docs_copy/archive/community/hustle_karma.todo rename to docs/archive/community/hustle_karma.todo diff --git a/docs_copy/archive/econ/a_brief_overview_of_system_policies.md b/docs/archive/econ/a_brief_overview_of_system_policies.md similarity index 100% rename from docs_copy/archive/econ/a_brief_overview_of_system_policies.md rename to docs/archive/econ/a_brief_overview_of_system_policies.md diff --git a/docs_copy/archive/econ/the_rulebook_at_genesis.md b/docs/archive/econ/the_rulebook_at_genesis.md similarity index 100% rename from docs_copy/archive/econ/the_rulebook_at_genesis.md rename to docs/archive/econ/the_rulebook_at_genesis.md diff --git a/docs_copy/archive/proposals/october_2022_governance_recap.md b/docs/archive/proposals/october_2022_governance_recap.md similarity index 100% rename from docs_copy/archive/proposals/october_2022_governance_recap.md rename to docs/archive/proposals/october_2022_governance_recap.md diff --git a/docs_copy/archive/proposals/proposal_2210_1_final_supply.md b/docs/archive/proposals/proposal_2210_1_final_supply.md similarity index 100% rename from docs_copy/archive/proposals/proposal_2210_1_final_supply.md rename to docs/archive/proposals/proposal_2210_1_final_supply.md diff --git a/docs_copy/archive/proposals/proposal_2210_2_proof_of_fee.md b/docs/archive/proposals/proposal_2210_2_proof_of_fee.md similarity index 100% rename from docs_copy/archive/proposals/proposal_2210_2_proof_of_fee.md rename to docs/archive/proposals/proposal_2210_2_proof_of_fee.md diff --git a/docs_copy/archive/proposals/proposal_2210_3_musical_chairs.md b/docs/archive/proposals/proposal_2210_3_musical_chairs.md similarity index 100% rename from docs_copy/archive/proposals/proposal_2210_3_musical_chairs.md rename to docs/archive/proposals/proposal_2210_3_musical_chairs.md diff --git a/docs_copy/archive/proposals/proposal_2210_4_repurpose_carpe.md b/docs/archive/proposals/proposal_2210_4_repurpose_carpe.md similarity index 100% rename from docs_copy/archive/proposals/proposal_2210_4_repurpose_carpe.md rename to docs/archive/proposals/proposal_2210_4_repurpose_carpe.md diff --git a/docs_copy/archive/proposals/proposal_2210_5_revenue_binding_primitives.md b/docs/archive/proposals/proposal_2210_5_revenue_binding_primitives.md similarity index 100% rename from docs_copy/archive/proposals/proposal_2210_5_revenue_binding_primitives.md rename to docs/archive/proposals/proposal_2210_5_revenue_binding_primitives.md diff --git a/docs_copy/archive/proposals/proposal_2210_6_faucets_for_workers.md b/docs/archive/proposals/proposal_2210_6_faucets_for_workers.md similarity index 100% rename from docs_copy/archive/proposals/proposal_2210_6_faucets_for_workers.md rename to docs/archive/proposals/proposal_2210_6_faucets_for_workers.md diff --git a/docs_copy/archive/proposals/proposal_2210_7_donor_directed_community_wallets.md b/docs/archive/proposals/proposal_2210_7_donor_directed_community_wallets.md similarity index 100% rename from docs_copy/archive/proposals/proposal_2210_7_donor_directed_community_wallets.md rename to docs/archive/proposals/proposal_2210_7_donor_directed_community_wallets.md diff --git a/docs_copy/archive/proposals/proposal_2210_8_infrastructure_escrow_funding.md b/docs/archive/proposals/proposal_2210_8_infrastructure_escrow_funding.md similarity index 100% rename from docs_copy/archive/proposals/proposal_2210_8_infrastructure_escrow_funding.md rename to docs/archive/proposals/proposal_2210_8_infrastructure_escrow_funding.md diff --git a/docs_copy/archive/proposals/scorpions_claw_proposal.md b/docs/archive/proposals/scorpions_claw_proposal.md similarity index 100% rename from docs_copy/archive/proposals/scorpions_claw_proposal.md rename to docs/archive/proposals/scorpions_claw_proposal.md diff --git "a/docs_copy/archive/proposals/spring_forward\302\240.md" "b/docs/archive/proposals/spring_forward\302\240.md" similarity index 100% rename from "docs_copy/archive/proposals/spring_forward\302\240.md" rename to "docs/archive/proposals/spring_forward\302\240.md" diff --git a/docs_copy/archive/proposals/team_arctika_recommendation.md b/docs/archive/proposals/team_arctika_recommendation.md similarity index 100% rename from docs_copy/archive/proposals/team_arctika_recommendation.md rename to docs/archive/proposals/team_arctika_recommendation.md diff --git a/docs_copy/archive/proposals/the_0l_network_constitution.md b/docs/archive/proposals/the_0l_network_constitution.md similarity index 100% rename from docs_copy/archive/proposals/the_0l_network_constitution.md rename to docs/archive/proposals/the_0l_network_constitution.md diff --git a/docs_copy/archive/technolgy/carpe_desktop_app.md b/docs/archive/technolgy/carpe_desktop_app.md similarity index 100% rename from docs_copy/archive/technolgy/carpe_desktop_app.md rename to docs/archive/technolgy/carpe_desktop_app.md diff --git a/docs_copy/archive/technolgy/developer_resources.md b/docs/archive/technolgy/developer_resources.md similarity index 100% rename from docs_copy/archive/technolgy/developer_resources.md rename to docs/archive/technolgy/developer_resources.md diff --git a/docs_copy/archive/technolgy/technology.md b/docs/archive/technolgy/technology.md similarity index 100% rename from docs_copy/archive/technolgy/technology.md rename to docs/archive/technolgy/technology.md diff --git a/docs_copy/assets/infrastructure-escrow-pledge-sensitivity.png b/docs/assets/infrastructure-escrow-pledge-sensitivity.png similarity index 100% rename from docs_copy/assets/infrastructure-escrow-pledge-sensitivity.png rename to docs/assets/infrastructure-escrow-pledge-sensitivity.png diff --git a/docs_copy/assets/summary-dilution-impacts.png b/docs/assets/summary-dilution-impacts.png similarity index 100% rename from docs_copy/assets/summary-dilution-impacts.png rename to docs/assets/summary-dilution-impacts.png diff --git a/docs_copy/assets/validator-opportunity-cost.png b/docs/assets/validator-opportunity-cost.png similarity index 100% rename from docs_copy/assets/validator-opportunity-cost.png rename to docs/assets/validator-opportunity-cost.png diff --git a/docs_copy/assets/wg-org-chart-example.png b/docs/assets/wg-org-chart-example.png similarity index 100% rename from docs_copy/assets/wg-org-chart-example.png rename to docs/assets/wg-org-chart-example.png diff --git a/docs_copy/cli-tools/_category_.json b/docs/cli-tools/_category_.json similarity index 100% rename from docs_copy/cli-tools/_category_.json rename to docs/cli-tools/_category_.json diff --git a/docs_copy/cli-tools/archived/tower_archived.todo b/docs/cli-tools/archived/tower_archived.todo similarity index 100% rename from docs_copy/cli-tools/archived/tower_archived.todo rename to docs/cli-tools/archived/tower_archived.todo diff --git a/docs_copy/cli-tools/archived/use_tower_cli_archived.todo b/docs/cli-tools/archived/use_tower_cli_archived.todo similarity index 100% rename from docs_copy/cli-tools/archived/use_tower_cli_archived.todo rename to docs/cli-tools/archived/use_tower_cli_archived.todo diff --git a/docs_copy/cli-tools/config.todo b/docs/cli-tools/config.todo similarity index 100% rename from docs_copy/cli-tools/config.todo rename to docs/cli-tools/config.todo diff --git a/docs_copy/cli-tools/first_steps.todo b/docs/cli-tools/first_steps.todo similarity index 100% rename from docs_copy/cli-tools/first_steps.todo rename to docs/cli-tools/first_steps.todo diff --git a/docs_copy/cli-tools/genesis.todo b/docs/cli-tools/genesis.todo similarity index 100% rename from docs_copy/cli-tools/genesis.todo rename to docs/cli-tools/genesis.todo diff --git a/docs_copy/cli-tools/getting_started.todo b/docs/cli-tools/getting_started.todo similarity index 100% rename from docs_copy/cli-tools/getting_started.todo rename to docs/cli-tools/getting_started.todo diff --git a/docs_copy/cli-tools/move/index.todo b/docs/cli-tools/move/index.todo similarity index 100% rename from docs_copy/cli-tools/move/index.todo rename to docs/cli-tools/move/index.todo diff --git a/docs_copy/cli-tools/node/index.todo b/docs/cli-tools/node/index.todo similarity index 100% rename from docs_copy/cli-tools/node/index.todo rename to docs/cli-tools/node/index.todo diff --git a/docs_copy/cli-tools/query/_category_.json b/docs/cli-tools/query/_category_.json similarity index 100% rename from docs_copy/cli-tools/query/_category_.json rename to docs/cli-tools/query/_category_.json diff --git a/docs_copy/cli-tools/query/balance.todo b/docs/cli-tools/query/balance.todo similarity index 100% rename from docs_copy/cli-tools/query/balance.todo rename to docs/cli-tools/query/balance.todo diff --git a/docs_copy/cli-tools/query/epoch.todo b/docs/cli-tools/query/epoch.todo similarity index 100% rename from docs_copy/cli-tools/query/epoch.todo rename to docs/cli-tools/query/epoch.todo diff --git a/docs_copy/cli-tools/query/getting_started.todo b/docs/cli-tools/query/getting_started.todo similarity index 100% rename from docs_copy/cli-tools/query/getting_started.todo rename to docs/cli-tools/query/getting_started.todo diff --git a/docs_copy/cli-tools/query/resources.todo b/docs/cli-tools/query/resources.todo similarity index 100% rename from docs_copy/cli-tools/query/resources.todo rename to docs/cli-tools/query/resources.todo diff --git a/docs_copy/cli-tools/query/val_config.todo b/docs/cli-tools/query/val_config.todo similarity index 100% rename from docs_copy/cli-tools/query/val_config.todo rename to docs/cli-tools/query/val_config.todo diff --git a/docs_copy/cli-tools/query/view.todo b/docs/cli-tools/query/view.todo similarity index 100% rename from docs_copy/cli-tools/query/view.todo rename to docs/cli-tools/query/view.todo diff --git a/docs_copy/cli-tools/txs/_category_.json b/docs/cli-tools/txs/_category_.json similarity index 100% rename from docs_copy/cli-tools/txs/_category_.json rename to docs/cli-tools/txs/_category_.json diff --git a/docs_copy/cli-tools/txs/generate_transaction.todo b/docs/cli-tools/txs/generate_transaction.todo similarity index 100% rename from docs_copy/cli-tools/txs/generate_transaction.todo rename to docs/cli-tools/txs/generate_transaction.todo diff --git a/docs_copy/cli-tools/txs/publish.todo b/docs/cli-tools/txs/publish.todo similarity index 100% rename from docs_copy/cli-tools/txs/publish.todo rename to docs/cli-tools/txs/publish.todo diff --git a/docs_copy/cli-tools/txs/transfer.todo b/docs/cli-tools/txs/transfer.todo similarity index 100% rename from docs_copy/cli-tools/txs/transfer.todo rename to docs/cli-tools/txs/transfer.todo diff --git a/docs_copy/cli-tools/txs/upgrade.todo b/docs/cli-tools/txs/upgrade.todo similarity index 100% rename from docs_copy/cli-tools/txs/upgrade.todo rename to docs/cli-tools/txs/upgrade.todo diff --git a/docs_copy/cli-tools/txs/validator.todo b/docs/cli-tools/txs/validator.todo similarity index 100% rename from docs_copy/cli-tools/txs/validator.todo rename to docs/cli-tools/txs/validator.todo diff --git a/docs_copy/cli-tools/wallet.todo b/docs/cli-tools/wallet.todo similarity index 100% rename from docs_copy/cli-tools/wallet.todo rename to docs/cli-tools/wallet.todo diff --git a/docs_copy/community programs/_category_.json b/docs/community programs/_category_.json similarity index 100% rename from docs_copy/community programs/_category_.json rename to docs/community programs/_category_.json diff --git a/docs_copy/community programs/a_good_list.md b/docs/community programs/a_good_list.md similarity index 100% rename from docs_copy/community programs/a_good_list.md rename to docs/community programs/a_good_list.md diff --git a/docs_copy/community programs/application_studio.md b/docs/community programs/application_studio.md similarity index 100% rename from docs_copy/community programs/application_studio.md rename to docs/community programs/application_studio.md diff --git a/docs_copy/community programs/danish_red_cross_humanitarian_fund.md b/docs/community programs/danish_red_cross_humanitarian_fund.md similarity index 100% rename from docs_copy/community programs/danish_red_cross_humanitarian_fund.md rename to docs/community programs/danish_red_cross_humanitarian_fund.md diff --git a/docs_copy/community programs/deep_technology_innovation_program.md b/docs/community programs/deep_technology_innovation_program.md similarity index 100% rename from docs_copy/community programs/deep_technology_innovation_program.md rename to docs/community programs/deep_technology_innovation_program.md diff --git a/docs_copy/community programs/ftw_ongoing_full_time_workers_program.md b/docs/community programs/ftw_ongoing_full_time_workers_program.md similarity index 100% rename from docs_copy/community programs/ftw_ongoing_full_time_workers_program.md rename to docs/community programs/ftw_ongoing_full_time_workers_program.md diff --git a/docs_copy/community programs/human_rewards_program.md b/docs/community programs/human_rewards_program.md similarity index 100% rename from docs_copy/community programs/human_rewards_program.md rename to docs/community programs/human_rewards_program.md diff --git a/docs_copy/community programs/moonshot_program.md b/docs/community programs/moonshot_program.md similarity index 100% rename from docs_copy/community programs/moonshot_program.md rename to docs/community programs/moonshot_program.md diff --git a/docs_copy/community programs/rxc_research_and_experimentation_0l_fund.md b/docs/community programs/rxc_research_and_experimentation_0l_fund.md similarity index 100% rename from docs_copy/community programs/rxc_research_and_experimentation_0l_fund.md rename to docs/community programs/rxc_research_and_experimentation_0l_fund.md diff --git a/docs_copy/community programs/social_infrastructure_program.md b/docs/community programs/social_infrastructure_program.md similarity index 100% rename from docs_copy/community programs/social_infrastructure_program.md rename to docs/community programs/social_infrastructure_program.md diff --git a/docs_copy/community programs/the_iqlusion_engineering_program.md b/docs/community programs/the_iqlusion_engineering_program.md similarity index 100% rename from docs_copy/community programs/the_iqlusion_engineering_program.md rename to docs/community programs/the_iqlusion_engineering_program.md diff --git a/docs_copy/community programs/tip_jar.md b/docs/community programs/tip_jar.md similarity index 100% rename from docs_copy/community programs/tip_jar.md rename to docs/community programs/tip_jar.md diff --git a/docs_copy/community programs/university_of_toronto_msrg.md b/docs/community programs/university_of_toronto_msrg.md similarity index 100% rename from docs_copy/community programs/university_of_toronto_msrg.md rename to docs/community programs/university_of_toronto_msrg.md diff --git a/docs_copy/community programs/working_group_key_roles.md b/docs/community programs/working_group_key_roles.md similarity index 100% rename from docs_copy/community programs/working_group_key_roles.md rename to docs/community programs/working_group_key_roles.md diff --git a/docs_copy/core-devs/_category_.json b/docs/core-devs/_category_.json similarity index 100% rename from docs_copy/core-devs/_category_.json rename to docs/core-devs/_category_.json diff --git a/docs_copy/core-devs/dev_quick_start.todo b/docs/core-devs/dev_quick_start.todo similarity index 100% rename from docs_copy/core-devs/dev_quick_start.todo rename to docs/core-devs/dev_quick_start.todo diff --git a/docs_copy/core-devs/formal_verification.todo b/docs/core-devs/formal_verification.todo similarity index 100% rename from docs_copy/core-devs/formal_verification.todo rename to docs/core-devs/formal_verification.todo diff --git a/docs_copy/core-devs/governance_fixtures.todo b/docs/core-devs/governance_fixtures.todo similarity index 100% rename from docs_copy/core-devs/governance_fixtures.todo rename to docs/core-devs/governance_fixtures.todo diff --git a/docs_copy/core-devs/move_coding_conventions.todo b/docs/core-devs/move_coding_conventions.todo similarity index 100% rename from docs_copy/core-devs/move_coding_conventions.todo rename to docs/core-devs/move_coding_conventions.todo diff --git a/docs_copy/core-devs/move_data_initialization.md b/docs/core-devs/move_data_initialization.md similarity index 100% rename from docs_copy/core-devs/move_data_initialization.md rename to docs/core-devs/move_data_initialization.md diff --git a/docs_copy/core-devs/readme.todo b/docs/core-devs/readme.todo similarity index 100% rename from docs_copy/core-devs/readme.todo rename to docs/core-devs/readme.todo diff --git a/docs_copy/core-devs/smoke_tests.todo b/docs/core-devs/smoke_tests.todo similarity index 100% rename from docs_copy/core-devs/smoke_tests.todo rename to docs/core-devs/smoke_tests.todo diff --git a/docs_copy/core-devs/testnet_deploy.todo b/docs/core-devs/testnet_deploy.todo similarity index 100% rename from docs_copy/core-devs/testnet_deploy.todo rename to docs/core-devs/testnet_deploy.todo diff --git a/docs_copy/edit-docs/_category_.json b/docs/edit-docs/_category_.json similarity index 100% rename from docs_copy/edit-docs/_category_.json rename to docs/edit-docs/_category_.json diff --git a/docs_copy/edit-docs/editing.md b/docs/edit-docs/editing.md similarity index 100% rename from docs_copy/edit-docs/editing.md rename to docs/edit-docs/editing.md diff --git a/docs_copy/index.md b/docs/index.md similarity index 100% rename from docs_copy/index.md rename to docs/index.md diff --git a/docs_copy/misc/_category_.json b/docs/misc/_category_.json similarity index 100% rename from docs_copy/misc/_category_.json rename to docs/misc/_category_.json diff --git a/docs_copy/misc/communtiy_wallet_activation.md b/docs/misc/communtiy_wallet_activation.md similarity index 100% rename from docs_copy/misc/communtiy_wallet_activation.md rename to docs/misc/communtiy_wallet_activation.md diff --git a/docs_copy/misc/genesis_instructions.todo b/docs/misc/genesis_instructions.todo similarity index 100% rename from docs_copy/misc/genesis_instructions.todo rename to docs/misc/genesis_instructions.todo diff --git a/docs_copy/misc/hot_upgrades.todo b/docs/misc/hot_upgrades.todo similarity index 100% rename from docs_copy/misc/hot_upgrades.todo rename to docs/misc/hot_upgrades.todo diff --git a/docs_copy/misc/key_rotation.todo b/docs/misc/key_rotation.todo similarity index 100% rename from docs_copy/misc/key_rotation.todo rename to docs/misc/key_rotation.todo diff --git a/docs_copy/misc/sybil_resistance.todo b/docs/misc/sybil_resistance.todo similarity index 100% rename from docs_copy/misc/sybil_resistance.todo rename to docs/misc/sybil_resistance.todo diff --git a/docs_copy/misc/tool_design.todo b/docs/misc/tool_design.todo similarity index 100% rename from docs_copy/misc/tool_design.todo rename to docs/misc/tool_design.todo diff --git a/docs_copy/misc/validator_registration.todo b/docs/misc/validator_registration.todo similarity index 100% rename from docs_copy/misc/validator_registration.todo rename to docs/misc/validator_registration.todo diff --git a/docs_copy/validators/_category_.json b/docs/validators/_category_.json similarity index 100% rename from docs_copy/validators/_category_.json rename to docs/validators/_category_.json diff --git a/docs_copy/validators/detailed_instructions.todo b/docs/validators/detailed_instructions.todo similarity index 100% rename from docs_copy/validators/detailed_instructions.todo rename to docs/validators/detailed_instructions.todo diff --git a/docs_copy/validators/genesis.todo b/docs/validators/genesis.todo similarity index 100% rename from docs_copy/validators/genesis.todo rename to docs/validators/genesis.todo diff --git a/docs_copy/validators/getting_started.todo b/docs/validators/getting_started.todo similarity index 100% rename from docs_copy/validators/getting_started.todo rename to docs/validators/getting_started.todo diff --git a/docs_copy/validators/hot_upgrades.todo b/docs/validators/hot_upgrades.todo similarity index 100% rename from docs_copy/validators/hot_upgrades.todo rename to docs/validators/hot_upgrades.todo diff --git a/docs_copy/validators/register.todo b/docs/validators/register.todo similarity index 100% rename from docs_copy/validators/register.todo rename to docs/validators/register.todo diff --git a/docs_copy/validators/rescue.todo b/docs/validators/rescue.todo similarity index 100% rename from docs_copy/validators/rescue.todo rename to docs/validators/rescue.todo diff --git a/docs_copy/validators/restore.todo b/docs/validators/restore.todo similarity index 100% rename from docs_copy/validators/restore.todo rename to docs/validators/restore.todo diff --git a/docs_copy/validators/validator_quickstart.todo b/docs/validators/validator_quickstart.todo similarity index 100% rename from docs_copy/validators/validator_quickstart.todo rename to docs/validators/validator_quickstart.todo diff --git a/docs_copy/validators/vfn_setup.todo b/docs/validators/vfn_setup.todo similarity index 100% rename from docs_copy/validators/vfn_setup.todo rename to docs/validators/vfn_setup.todo diff --git a/docs_copy/validators/with_docker_setup.todo b/docs/validators/with_docker_setup.todo similarity index 100% rename from docs_copy/validators/with_docker_setup.todo rename to docs/validators/with_docker_setup.todo diff --git a/docs_copy/validators/yaml-templates/_category_.json b/docs/validators/yaml-templates/_category_.json similarity index 100% rename from docs_copy/validators/yaml-templates/_category_.json rename to docs/validators/yaml-templates/_category_.json diff --git a/docs_copy/validators/yaml-templates/fullnode-yaml.todo b/docs/validators/yaml-templates/fullnode-yaml.todo similarity index 100% rename from docs_copy/validators/yaml-templates/fullnode-yaml.todo rename to docs/validators/yaml-templates/fullnode-yaml.todo diff --git a/docs_copy/validators/yaml-templates/validator-yaml.todo b/docs/validators/yaml-templates/validator-yaml.todo similarity index 100% rename from docs_copy/validators/yaml-templates/validator-yaml.todo rename to docs/validators/yaml-templates/validator-yaml.todo diff --git a/docs_copy/validators/yaml-templates/vfn-yaml.todo b/docs/validators/yaml-templates/vfn-yaml.todo similarity index 100% rename from docs_copy/validators/yaml-templates/vfn-yaml.todo rename to docs/validators/yaml-templates/vfn-yaml.todo diff --git a/docs_old/about/_category_.json b/docs_old/about/_category_.json deleted file mode 100644 index 64db3e0a..00000000 --- a/docs_old/about/_category_.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "label": "About", - "position": 1, - "link": { - "type": "generated-index", - "description": "The big picture" - } -} diff --git a/docs_old/about/engineering_strategy.todo b/docs_old/about/engineering_strategy.todo deleted file mode 100644 index 84947f58..00000000 --- a/docs_old/about/engineering_strategy.todo +++ /dev/null @@ -1,91 +0,0 @@ -# ENGINEERING STRATEGY - -The engineering strategy is in line with the overall community goal: optimize for being opinionated about economic policy, and having long-term optionality in picking infrastructure vendors. - -In 0L the content (our coin) is the priority. It's too risky being your own infrastructure stack vendor during a standards war. Instead, optimize for longevity and portability of the native asset and its policies. - -As such, 0L's innovations are in the middleware and application layers primarily in regards to economic policy. We intentionally rely heavily on (wonderful and cutting edge) infrastructure vendors, and aim to be agnostic for when the inevitable next technology wave arrives. - -# DEPENDENCY MANAGEMENT - -Our code management strategy means we separate some concerns and have clear APIs between each major system component. - -- `Libra Framework`: is responsible for the framework source and tools to test and deploy etc. This is mostly original source that wraps or relies heavily on Move Language and Diem Platform (see below). -- `Carpe`: is currently a wallet. Before version V7, it was also a light miner that included the tower. This is original source that imports our libra-tools. -- `Tower`: is the verifiable delay function proof-of-work system 0L used to bootstrap and mint all the coins up to V7. This is original source, lightly uses `libra-tools`. -- `Libra-Tools`: low level CLIs and libraries for wallets, transactions, queries. This is original source that relies heavily on Diem Platform. -- `Diem Platform`: is infrastructural network node source (database, consensus, networking, configs, testing). There are linear commits to Facebook's Diem and today is maintained primarily by Matonee Inc (Aptos). -- `Move Language`: is the language spec, standard library, virtual machine, and dev tools. There are linear commits to Facebook's Move source, and today is primarily maintained by Mysten Labs Inc (Sui). - -# Commit History - -## Hello World - -The commit history of `ol/diem-platform` will show that 0L forked Facebook's Libra (later renamed Diem) on their launch day in June 2019. Facebook was our first vendor. - -## 2019 - -A majority of the work in 2019 existed in separated now deprecated projects; `ol/movemint` for example, based on Cosmos SDK tooling. - -On the `diem-platform` repo the majority of the work began in Q4 2019, where we maintained the Diem monorepo structure. - -We added our cryptography ceremony (Towers) and policy layers to mostly \*.mvir (Yes, we were writing in the Move Intermediary Representation before the Move language existed properly!). - -## 2020 - -The V1 0L public mainnet was launched in Q3 2020 . Fun fact, you can see our crypto seeds based on contemporaneous news of the pandemic period. - -That code was based on commit from Facebook Diem v 1.4. - -## 2021 - -The V2 Public Network happened in November 2021, based on Facebook Diem 1.5 . - -Mysten Lab's Sui platform started their Move framework on Dec 2 2021: https://github.com/MystenLabs/sui/commit/2c26b167a3fede5c892a64a4d6c68e6b56ed2e30. - -## 2022 - -The Move Language repo became decoupled into its own repo on January 7th 2022. See `move-language` [first commit here](https://github.com/move-language/move/commits/98ed299a7e3a9223019c9bdf4dd92fea9faef860). Compare: [diem#5af34](https://github.com/0LNetworkCommunity/diem/commit/5af341e53c9a24ebe24596f4890fcaaef3bcdc54), and [move-language#5af34](https://github.com/move-language/move/commit/5af341e53c9a24ebe24596f4890fcaaef3bcdc54). - -On Feb 18th 2022, Facebook effectively ended maintenance of Diem at commit `50925260829a84d7a07b7f1922fcefc3b8147a2d`. - -0L V6 was based on that end-of-the-line Diem code. - -Matonee's Aptos Platform forked Diem that commit. Compare: [aptos#50925](https://github.com/aptos-labs/aptos-core/commit/50925260829a84d7a07b7f1922fcefc3b8147a2d) and [diem#50925](https://github.com/diem/diem/commit/50925260829a84d7a07b7f1922fcefc3b8147a2d). More info here: https://github.com/aptos-labs/aptos-core/pull/14 - -## 2023 - -We split our `libra` repo (with linear history to Facebook's first commit) into `libra-framework` and `diem-platform`. . As far as we know this is the only maintained version of Libra aside from vendor forks. - -0L continues to maintain Diem under `diem-platform` pulling in the (excellent -and ninja) maintenance upgrades from Matonee since commit `#509252`. V7 -production release is freezed at [vendor's #4cb85b](https://github.com/aptos-labs/aptos-core/commit/4cb85bc832b57acb26a627182163be6de2f9d83f) - -## Light Touch - -Most of the Diem Platform Vendors publish code in "monorepo" code repositories. This means much of vendor code is tightly coupled. This is improving over time (there was a time when the Move Language was only developed in the Facebook/Diem/Diem repository). - -We attempt to have a light touch approach with all our dependencies, to prevent the amount of forks we maintain. - -## Extend and Layer - -We first and Always try to work with unmodified dependencies. - -- We always extend APIs where we import them. For example create new Diem Platform rust `traits` in Libra Framework to extend the functionality we need. -- Duplicate the code in the worst case, if it is a single function or small module. -- Mirror copies of critical policy code which doesn't have package management (Move standard libraries and diem framework) - -## Vendorize Dependencies - -Sometimes maintaining our own branch is inevitable, especially in newly emergent technologies. - -When we must change an upstream dependency: - -- visibility: we should aim to only ever make changes to the visibility of functions and objects in upstream code. This creates a clean abstraction between platform vendor tools, and libra-specific features. -- naming: sometimes, the vendors change names (:/) so we need to rename things back. sigh. -- decoupling: there are hard-coded terms in vendor code, such as urls, coin names, directories, commands, config files, etc. We need to separate those and make generic. - -## Easy Rebases - -- on our fork we consider our main branch `libra-framework`, which contains all of our changes. The changes should be linear so to be _rebased_ without conflict. -- the fork keeps the `main` branch which can be synced, and the changes are rebased onto `libra-framework` branch. diff --git a/docs_old/about/getting_started.todo b/docs_old/about/getting_started.todo deleted file mode 100644 index f18439ac..00000000 --- a/docs_old/about/getting_started.todo +++ /dev/null @@ -1,84 +0,0 @@ ---- -title: "Getting Started" -sidebar_position: 1 -description: 'Developing on the 0L Network' ---- - -# Getting Started ---- - -## Tech Strategy -The tech strategy in line with overall community goals: optimize for being opinionated about economic policy, and having long-term optionality in picking infrastructure vendors. - -The content is the priority. It's too risky being your own infrastructure stack vendor during a standards war. Instead, optimize for longevity and portability of the native asset and its policies. - -As such 0L's innovations are in the middleware and application layers primarily in regards to economic policy. We intentionally rely heavily on (wonderful and cutting edge) infrastructure vendors, and aim to be agnostic for the inevitable next technology wave arrives. - -## Dependency Management -Our code management strategy means we separate some concerns and have clear APIs between each major system component. -- `Libra Framework`: is responsible for the framework source and tools to test and deploy etc. This is mostly original source that wraps or relies heavily on Move Language and Diem Platform (see below). -- `Carpe` is a reference light miner and wallet. This is original source imports our libra-tools and tower. -- `Tower`: is the verifiable delay function proof-of-work system 0L used to bootstrap and mint all the coins up to V7. This is original source, lightly uses `libra-tools`. -- `Libra-Tools`: low level CLIs and libraries for wallets, transactions, queries. This is original source that relies heavily on Diem Platform. -- `Diem Platform`: is infrastructural network node source (database, consensus, networking, configs, testing). There are linear commits to Facebook's Diem and today is maintained primarily by Matonee Inc (Aptos). -- `Move Language`: is the language spec, standard library, virtual machine, and dev tools. There are linear commits to Facebook's Move source, and today is primarily maintained by Mysten Labs Inc (Sui). - - - -## Commit History - -### Hello World -The commit history of `ol/diem-platform` will show that 0L forked Facebook's Libra (later renamed Diem) on their launch day in June 2019. Facebook was our first vendor. - -### 2019 -A majority of the work in 2019 existed in separated now deprecated projects; `ol/movemint` for example, based on Cosmos SDK tooling. - -On the `diem-platform` repo the majority of the work begain in Q4 2019, where we maintained the Diem monorepo structure. - -We added our cryptography ceremony (Towers) and policy layers to mostly *.mvir (Yes, we were wrting in the Move Intermediary Representation before the Move language existed properly!). - -### 2020 -The V1 0L public mainnet was launched in [Q3 2020](https://github.com/0LNetworkCommunity/genesis-registration). Fun fact, you can see our crypto seeds based on contemporaneous news of the pandemic period. - -### 2021 -That code was based on commit (TODO: XYZ) from Facebook Diem v 1.4. The V2 Public Network happened in November 2021, based on Facebook Diem 1.5 (TODO: Commit). - -### 2022 -The Move Language repo became decoupled into its own repo in january 2022 (TODO: commit history). - -Matonee's Aptos Platform forked Diem at commit XYZ in March 2022. (Note: the commit history appears to have rebased and commit hashes have changed). - -0L V6 was based on the end-on-of-the-line Facebook commit XYZ (Same as Aptos). - -Mysten Lab's Sui platform forked Move Language at commit XYZ in (TODO October 2022?) - -### 2023 -0L V7 pulled in the (excellent and ninja) maintenance upgrades from Matonee since commit XYZ. - -0L separated our `libra` repo (with linear history to Facebook's first commit) into `libra-framewok` and `diem-platform`. - -## Light Touch - -Most of the Diem Platform Vendors publish code in "monorepo" code repositories. This means much of vendor code is tightly coupled. This is improving over time (there was a time when the Move Language was only developed in the Facebook/Diem/Diem repository). - -We attempt to have a light touch approach with all our dependencies, to prevent the amount of forks we maintain. - -## Extend and Layer -We first and Always try to work with unmodified dependencies. - -- We always extend APIs where we import them. For example create new Diem Platform rust `traits` in Libra Framework to extend the functionality we need. -- Duplicate the code in the wost case, if it is a single function or small module. -- Mirror copies of critical policy code which doesn't have package management (Move standard libraries and diem framework) - - -## Vendorize Dependencies -Sometimes maintaining our own branch is inevitable, especially in newly emergent technologies. - -When we must change an upstream dependency: -- visibility: we shoul aim to only ever make changes to the visibility of functions and objects in upstream code. This creates a clean abstraction between platform vendor tools, and libra-specific features. -- naming: sometimes the vendors change names (:/) so we need to rename things back. sigh. -- decoupling: there are hard-coded terms in vendor code, such as urls, coin names, directories, commands, config files, etc. We need to separate those and make generic. - -## Easy Rebases -- on our fork we consider our master branch `libra-framework`, which contains all of our changes. The changes should be linear so to be *rebased* without conflict. -- the fork keeps the `main` branch which can be synced, and the changes are rebased onto `libra-framework` branch. \ No newline at end of file diff --git a/docs_old/about/historical_tech_stack.todo b/docs_old/about/historical_tech_stack.todo deleted file mode 100644 index 16cc8526..00000000 --- a/docs_old/about/historical_tech_stack.todo +++ /dev/null @@ -1,156 +0,0 @@ -# ARCHIVE: 0L's Tech Strategy 2020 - -## What we are doing -0L's technology strategy is to stay as close as possible to the Libra/Diem code base. - -This is because fragmenting the technology products on offer will lead to confusion, and eventually to lack of maintenance and stagnation. This is best for the wider open source ecosystem these tools extend and depend upon. It's also much more efficient on resources. Libra/Diem is a massive project, and simply keeping up to date with the code updates requires a dedicated team. Let alone making additions. Separate from Libra/Diem, The 0L project on its own has contributed tens of thousands of lines of new code. - -So the forking strategy is simple in concept: take the unmodified Diem code, and import it into the 0L project and add layers of features. Though it's not that simple in execution because of the nature of the code base. We have to insert many changes in strategic places of the diem-core code, in order for the 0L layers and side-cars to work. In short, it's not a simple code merge, it takes about two weeks from start to finish to incorporate a new upstream Diem release into 0L. - -## What we inherited - -The Libra/Diem platform is a spaceship on all accounts. There are engineering breakthroughs throughout the project. The architecture is sensibly designed, and expertly assembled. This is the merit of the Facebook engineering team (who as individuals appear to true believers in the power of these technologies, and one should make no assumptions of their views on corporate strategy). - -This is a non-exhaustive summary of the key features of the Diem architecture that are worth paying attention to. We'll take it from the top of the stack to the bottom. - -### The Move Language -The smart-contract language of the platform is called Move. It is the most unique breakthrough of the team. This is a language that is designed to be extremely safe in adversarial environments, and for hurried, less experienced developers. It's a very ergonomic language, it's easy to approach it if you have even entry-level coding experience. In terms of safety it incorporates much from the Rust language concepts of "borrowing" memory. The compiler is pretty obnoxious, which is something you want when designing autonomous financial systems. One standout feature of the Move language is built-in Formal Verification. Adjacent to the code you can write specs for invariants which your code must preserve (i.e. this function should never be called by this type of account), and it can be checked during the development and build process. This is unique and powerful. - -### Programming model -The execution of the smart contract and scripts has some subtle but important safety features. By design what are referred to in other platforms as smart-contracts are in fact "modules" here. Users can publish modules, which any other module or transaction can import. This is important. The transactions are scripts. So compared to Ethereum, much of what happens in a smart contract, can actually be split into long lived code in a module, and transaction-scripts which can import from the module (and other modules). This decoupling allows for powerful composability and reliability. The developer can evolve the application without necessarily needing to upgrade modules every time a new transaction use-case emerges. - -Modules can have "resources" bound to them. A resource can be thought of as an object in memory, but with restrictions: they can only be modified by the module that instantiated them, and are restricted in how they get created and transferred. Writing a non-fungible token is basically just instantiating one such structure, and something like a fungible token, can be done in a handful of lines of code. - -### Standard Library -This is a minor and easily overlooked architectural decision that is quite powerful. There are many modules that are provided standard by the chain, published to the 0x1 address. This standard library can be imported into user-defined modules and transaction scripts. - -Importantly, much of the logic tangential to consensus (e.g. validator inclusion in validator set) which would ordinarily be done in the protocol layer (i.e in Rust) is actually written in Move and is stored in the application layer. That is, much of the system policies are just state in the chain database. This makes upgrades to many aspects of system management trivial. Notably in Diem's case, this is done by a centralized party (see below how we had to modify this). - -### The Move VM -This is a purpose-built bytecode execution environment which isolates the Move Language from the state transition core. The unique feature of the Move VM is that it is easily extensible. It's very easy to include a new instruction to the virtual machine, a "native function". The native functions are written in Rust (which is the language of the entire code-base). Below we reference some of the changes we had to make for real-world use cases. - -### Executor -This is another place where the Libra/Diem architecture shines, and still has opportunity to evolve over the long term. The most important feature of the Execution layer is "decoupled execution". This is an important breakthrough. Typically in blockchains all transactions are handled sequentially, there can be no parallelization. With decoupled execution, on the other hand, the executor service checks if a transaction can successfully be processed in parallel to other operations in the mempool. That is: if the transaction could be executed in isolation, and the state changes are atomic. - -This places Libra/Diem in a rarified company, the transaction throughput is massively scaled because of this architectural choice, and skillful engineering. It also lays the groundwork for further optimizations possible, and likely coming down the path including the Narwhal DAG mempool management paper Facebook released recently. - -### Mempool -The mempool management is different from typical blockchains where transactions within the mempool are propagated (e.g. with gossip protocol) without guarantees of inclusion by other parties. In Libra, a Validator node receiving a transaction has the task of making sure the transaction is included in all other validator's mempools. This change allows voting on proposals to happen faster, and more orderly than other methods. - -### Consensus -There's a lot to be said about how consensus happens on blockchains, and we won't attempt to go into any depth here. The LibraBFT consensus is a variation on Hotstuff, itself a variation of classical consensus algorithm pBFT. LibraBFT borrows much from HotStuff leveraging consensus linearity wherein an agreement on a message is reached in a single round. Pipelining of blocks in HotStuff guarantees the finality of the proposed block by the third block following the proposed block. Effectively block production is only gated by the network speed, the speed in which blocks can be propagated to other nodes. - -### Storage -The database which stores the transactions is based on a Sparse Merkle Tree design called Jellyfish. This is an architecture shared by a number of blockchains. It has the benefit of being fast to search, and occupies less storage space (hashes) than a traditional merkle tree. The storage is backed by a RocksDB key-value store. This is a sensible design. There isn't much to remark here, except that there are still opportunities that can be leveraged from this storage architecture to allow for faster syncing of the blockchain. - -### What had to Change - -The technology we are inheriting is a spaceship. It is also purely infrastructural. There's very little in the way of tooling or smart contracts that are usable in the real world. We assume much of the remainder of the software stack is closed-sourced at Facebook. - -But most importantly, the architecture is designed as a private, consortium chain. - -For system administration, there is on omnipresent Diem Association account. Yes, a private key that controls many functions including: Freezing accounts (!), selecting validators for inclusion, paying transaction fees to validators, upgrading the system code. This is obviously a non-starter. So a lot of work had to go into making system policies execute in a permissionless environment. - -We also had to add Sybil resistance mechanisms. Typically communities have been choosing Proof-of-Stake as the Sybil resistance method for BFT networks. This is not the route we chose given community growth considerations (as well as regulatory). Elsewhere we've talked in detail about our Delay Towers complement to consensus. - -Also there were a number of instructions we wanted to add to the MoveVM so that people could write the types of contract they wanted. - -Lastly, there was nothing in Libra/Diem about economics. Meaning, there's nothing in the way of game theory, about how the network is supposed to perform in a permissionless environment. For example: the transactions are metered in USD stablecoins in LIbra/Diem architecture, and paid out by the administrator, and there's no word anywhere about subsidies that may be needed in the absence of meaningful transaction fees. As such there's no consideration to the performance of the validator nodes, all nodes are assumed to be monitored external to the protocol. So we had to rethink a number of things given some of the technical features of the network. The network has novel features, so economic mechanisms we see in other chains would not be drop-in replacements. This was a significant amount of research. - - -## Our Contributions - -This is not an exhaustive summary of the changes. 0L contributed about 40k new lines of code to the code-base, not including changes and code removal. It's a summary of what we think makes 0L a compelling network. - -### Removing the Root Account - -This is an obvious decision. But the task propagated into many subprojects. The Root Account is pervasive in the codebase. So we had two things to accomplish: (1) replace all its functions with a system 0x0 account (2) Neuter the Root Account where impossible to remove (e.g. in much of the genesis logic). -Decentralized Genesis -Beginning with Genesis, the Libra/Diem architecture provides good tooling on creating genesis blocks, mainly for testing. For an actual network genesis, the tools assume that there is an administrator that is picking the participants and then setting a layout file. - -In our changes we made it such that an online Github repo acted as a gathering place for anyone who wished to "register" to be part of a genesis. The owner of the repo, would have as a policy in the genesis ceremony, to accept all pull requests or people adding their genesis validator configurations. In our genesis, all candidates had to submit a Delay Tower "proof zero", an initial proof of work. All registrants are expected to provide their own layout file. This means that several genesis blocks (and hence networks) are possible with the initial genesis. After a few attempts and some social consensus a canonical chain will emerge. This may appear unpredictable, but it has the benefit of being a maximally decentralized genesis ceremony. - -### Delay Towers - -This is the deprecated Proof of Work sybil resistance used to bootstrap the -network. Mining was deprecated on v6 upgrade during 11/2023. -We needed a way to choose what validators were allowed to operate in a validator -set. We did this without Proof of Stake. In short, Delay Towers prove sequential -proofs of elapsed time. This can be considered a "heavy" identity, enough for -the BFT requirements of there being a durable identity, which is not cheap. This -was a significant amount of research and experimentation. - -See the long form paper here: https://siasky.net/IAA8rbRgFQLQVnGVWLf5RP0j2MLV7KsxcThqeOlp1pn2_Q - -### Hot Upgrades -While there's a long discussion possible on how network upgrades should be selected (governance), there was no starting place for that conversation, when the system could only be updated by the root account (that we removed). Read more about the Hot Upgrade procedure here: (TODO) - -We invented an upgrade mechanism for BFT, which does not require hard forks, nor operator intervention at the time of upgrade. - -Since all system rules are encoded in the application layer in Diem, the code is quite compact, and a proposed new binary could also be stored in the applications layer. Since that's possible it also opens up the binary to be voted on chain, and the code of the upgrade itself, stored on-chain, such that the upgrade can happen without operator intervention. New binaries for the system can be proposed and voted upon by the validators, and if there are โ…” of validators choosing the binary (effectively what would be needed for a hard fork), the changes would be synchronously written by all validator nodes at a coordinated time in the blockchain. - -### Validator Stats - -We had to have on-chain information on the performance of validators. This is critical to designing any economic games around transaction fees and other rewards. - -Fortunately in the upstream code, the block prologue is executed in the Move virtual machine, and allows us to add transaction metadata directly into the state machine on every block. So the 0x0 system address contains information on what validators have voted on a given block, and who the proposer was. We can use this for some naive metering within the state machine. It's a sufficient amount to be able to identify which validator nodes are not performing and apply certain sanctions. - -There is a performance penalty for this, and optimizations are possible. Since Move does not offer higher order data structures (hash tables) the data is stored in tables which are not ideal for traversing. - -### Onboarding of accounts - -In the upstream LibraDiem code, accounts are not created permissionlessly. It starts with a Diem Association Account, which later add Virtual Asset Service Providers (such an exchange), which later create user accounts. So all of this had to be replaced (the code remains in our code base for reference, but is inactivated). -Instead, there are only two types of accounts on 0L: end-user accounts (the typical account), and Validator Accounts (who own and operate nodes). - -End user accounts can be created by anyone that already has an account, as is typical with any account-based blockchain. Like in Ethereum, you can create keys for an account offline, but the account does not exist until someone already on-chain sends you at least one coin. - -Similarly for Validator accounts, an account needs to be created by another pre-existing Validator account. There are some game theoretical considerations here which are discussed in the Rulebook. In short, unlike industry practice where the group of validators have to vote on admission of a new member, in 0L any validator can onboard another, but they are rate-limited from onboarded too many. One validator can onboard another every 14 epochs (days). - -Tangentially, but relevant. Any accounts can optionally create different policies on them called Slow Wallets or Community Wallets. This is described in the rule book. - -### MoveVM changes - -We've made some additions to the MoveVM that were necessary for us to implement Delay towers and so that users could write useful financial apps. - -- Decimal - we needed a number type that could be used for financial math that could lead into polynomial curves etc. So we added the Rust Decimal library and some initial APIs and their corresponding native instructions. - -- VDF verification - to verify the Delay Towers proofs we added the ChiaVDF verifier to the VM. The prover is not needed in the VM. The VDF prover can accept a number of parameters (not hardcoded for 0L's use-case). So application builders could leverage it in their own games. - -### Auto Pay -The ability to create payments in the future, and regular payments as a percent of account balance or of new income. This was a feature requested early by the community. It powers a number of use-cases important at the start of a network. -Namely it is useful for anyone that wants to run a community program. In this case an entity or a person is seeking to accomplish a goal or a project, and is asking for donations. Autopay allows for set-it-and-forget-it donations to programs. Most people in 0L use this to send a portion of their mining rewards to programs automatically. - -Autopay can be programmed for: - -- Sending a single payment in the future. -- Sending recurring flat fee payments every epoch (day). -- Sending a percent of the balance every epoch. -- Sending a percent of NEW balance every epoch (e.g. mining rewards). - -Future types of autopay are possible. Autopay has a simple First In First Out Queue, to handle planned payments that go above the current balance or above current transfer restrictions. -CLI -Lots of tooling had to be written to successfully manage nodes and interact with accounts. Much of the tooling is in early stages given the ground that had to be covered given the complexity of the system. - -### Web Monitor -a web interface for a Nodes Operator to see reports on the node. -Basic chain info: Epoch number, waypoint. -Includes Node Health, and account info -Performance reports on all validators in set. -JSON endpoints to query data, like the node's account profile, epoch. -Not to be confused with a fullnode json-rpc - -### Terminal Explorer -Explorer - a terminal block explorer. This one is mostly for fun. This is a terminal interface for a block explorer to check some vitals of your fullnode or validator node. - -### TXS -We needed a library for sending different types of transactions. So that it could be imported in other tools. TXS also include a CLI utility to send commands from terminal. - -### Onboard -This is a library and CLI tool for creating packaging all of the necessary files for a new fullnode or validator account to join the network. Because 0L changed the account creation permissions and logic, there had to be purpose built tooling for it. - -### Restore -Diem has one significant limitation which is a slower sync time. A fullnode joining an already mature network, will take a long period of time to catch up to consensus. So we had to create tools and a bit of infrastructure to leverage some of Diem's existing backup and restore tools. -At every new epoch there is a snapshot taken of the chain, and submitted to a Github repository. Multiple such repositories can exist. When a new validator is joining the network they must begin as fullnodes. The ol restore tool will fetch a snapshot from repository, check it, and deploy it so that the fullnode can begin syncing from an advanced epoch (i.e. waypoint). - -### Carpe -Last but not least. We wanted all users to be able to participate meaningfully, and on equal footing with a protocol. Since there is a subsidy for creating heavy identities on the chain (Delay Tower), we needed to make this accessible to a diverse audience. The Carpe app, combines a Wallet with a Light Miner, which allows anyone with a desktop whether Windows, Ubuntu, or Mac, to "mine" coins for themselves. diff --git a/docs_old/archive/_category_.json b/docs_old/archive/_category_.json deleted file mode 100644 index f5a434b1..00000000 --- a/docs_old/archive/_category_.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "label": "Archive", - "position": 10, - "link": { - "type": "generated-index", - "description": "Historical, canonical, and/or deprecated for reference" - } -} diff --git a/docs_old/archive/announcements/news/carpe_beta_launched.md b/docs_old/archive/announcements/news/carpe_beta_launched.md deleted file mode 100644 index ae021c15..00000000 --- a/docs_old/archive/announcements/news/carpe_beta_launched.md +++ /dev/null @@ -1,22 +0,0 @@ - -10 Feb 2022 -- With the launch of the beta version of the Carpe Desktop App, the 0L Network has taken the next step towards making it possible for anyone to run a miner and earn crypto rewards. - - - - -Carpe is a desktop wallet and miner that runs on the new 0L Network blockchain. The app is lightweight and designed to help you establish your digital identity in the 0L Network, while paying you coins to do so. Carpe is a standalone desktop application that will run on any contemporary Windows or Mac machine. The app is gentle on your resources, meaning that you can continue to use your computer normally while the app runs in the background. Simply install it, turn it on, and start earning tokens. - - - - -Today's release is the Beta of Carpe. The new version includes an improved interface and user experience and, under the hood, auto-update and automatic network connections. With this release, the community would also like to thank the over 3,000 (!!) alpha testers who have helped us bring Carpe to where it is today. - - - - -**To get started, [follow this link](https://github.com/0LNetworkCommunity/carpe)**. We've also created a set of easy to follow instructions, including [a video tutorial](https://youtu.be/FcPiiZNS8sA). Additionally, [you can also find a welcoming community of people that would be happy to help you on our Discord Server. Join us!](https://discord.gg/Ry2cf4NrbS) - - - - -Carpe Diem diff --git a/docs_old/archive/announcements/news/carpe_goes_multilingual.md b/docs_old/archive/announcements/news/carpe_goes_multilingual.md deleted file mode 100644 index 6ca10068..00000000 --- a/docs_old/archive/announcements/news/carpe_goes_multilingual.md +++ /dev/null @@ -1,14 +0,0 @@ - -We've released, today, a new version of the 0L Network's Carpe Wallet \& Desktop Miner. This release (v.0\.3\.0\) is our latest release in the Carpe Beta series and includes significant new functionality, including multilingual support and a new tab "Events", which displays a list of events associated with your account (i.e., when coins move in and out of the wallet). This latest version ships with Chinese, Portuguese, and French language support. It is our plan to add additional languages in the near future. - - - - -To upgrade to the latest version, simply shut down and then restart your Carpe instance. You should be prompted to install the new version. Thanks to all on the Dev Team for making this happen! For those of you who are new to Carpe, [follow this link to grab the installer](https://github.com/0LNetworkCommunity/carpe) for Mac or WIN - - - - -To learn more about Carpe, visit the dedicated page on this site: [http://openlibra.blog/technology/carpe\-desktop\-app/](http://openlibra.blog/technology/carpe-desktop-app/) - - diff --git a/docs_old/archive/announcements/news/new_milestones_for_carpe.md b/docs_old/archive/announcements/news/new_milestones_for_carpe.md deleted file mode 100644 index 76ae9891..00000000 --- a/docs_old/archive/announcements/news/new_milestones_for_carpe.md +++ /dev/null @@ -1,50 +0,0 @@ - -The 0L Network today reached a new record in terms of activity on the network: The daily number of active Carpe miners topped 2,000 for the first time today, with 2,080 installations running and earning tokens today. The number of active Carpe miners has been increasing steadily across the last 30 days, as new users have joined the community and discovered how easy it is to run Carpe and earn rewards. - - - - -Also on this date we have released a newly updated version of Carpe \- version 0\.5\.0\. Here's what's new: - - - - -* Wallet\-to\-wallet coin transfers -* Better reliability connecting to the chain -* Dynamic VDF proofs (improving network and miner performance!) -* Over\-the\-air upgrades -* Support for localization in multiple new languages - - - - -For the next few days, you will need to manually download and install Carpe. The automatic updater will be enabled after weโ€™ve given our more experienced users a chance to install the new version manually and report back on their experience. - - - - -Here are the links for the packages you need for a manual update: - - - - -* Windows users: [https://github.com/0LNetworkCommunity/carpe/releases/download/v0\.5\.0/carpe\_0\.5\.0\_x64\.msi](https://github.com/0LNetworkCommunity/carpe/releases/download/v0.5.0/carpe_0.5.0_x64.msi) -* MacOS users (11\+ only): [https://github.com/0LNetworkCommunity/carpe/releases/download/v0\.5\.0/carpe\-macos\-11\.dmg](https://github.com/0LNetworkCommunity/carpe/releases/download/v0.5.0/carpe-macos-11.dmg) -* Debian users: [https://github.com/0LNetworkCommunity/carpe/releases/download/v0\.5\.0/carpe\_0\.5\.0\_amd64\.deb](https://github.com/0LNetworkCommunity/carpe/releases/download/v0.5.0/carpe_0.5.0_amd64.deb) - - - - -For those of you unfamiliar with Carpe, it is a wallet and light miner application that can run on most consumer computers. The app only requires 1 thread of your CPU, meaning not only can most machines run it, but you can run it in the background while you do other things with your machine. Download Carpe, learn about 0L and start receiving rewards \- itโ€™s very easy to get started. - - - - -Kudos to all of the Carpe contributors and the top\-tier 0L community for pressing on during this crypto winter. Itโ€™s time for builders to build! We welcome all builders into the community and encourage you to explore this site to learn more and [drop by our Discord and say hi](https://discord.gg/Nw7MpczV4X). - - - - -Carpe diem! - - diff --git a/docs_old/archive/announcements/news/press_mysten.md b/docs_old/archive/announcements/news/press_mysten.md deleted file mode 100644 index c0a0349c..00000000 --- a/docs_old/archive/announcements/news/press_mysten.md +++ /dev/null @@ -1,59 +0,0 @@ - -ย  - - - - - -#### Press Release - 1 Feb 2022 - - - - - - -## Mysten Labs Partners With 0L Network to Expand Move For Secure Smart Contracts - - - - - - -Mysten Labs, a Web 3\.0 infrastructure company, announced a partnership with 0L Network, an open and permissionless version of the Diem blockchain. Together, Mysten Labs and 0L will build tools and resources for the Move smart contract programming language. Move, released as part of the Diem technology stack, is uniquely effective for secure smart contract development. In line with the partnership, the projects plan to roll out joint Move hackathons and mentorship programs starting in March 2022\. - - - - - -[Read Full Article](https://www.globenewswire.com/news-release/2022/02/01/2377039/0/en/Mysten-Labs-Partners-With-0L-Network-to-Expand-Move-For-Secure-Smart-Contracts.html) - - - - - - - -#### The Defiant - 16 Nov 2021 - - - - - - -## 0L Aims To Revive Facebookโ€™s Libra Cryptocurrency With Fair Launch - - - - - - -Every now and then folks adjacent to crypto Twitter like to tweet out some version ofย โ€œRemember Libra?โ€. Libra was Facebookโ€™s first effort to get in on the decentralized web, with a bold promise to โ€œbank the unbankedโ€ via blockchain that was revealed in mid-2019\. The worldโ€™s largest social networkย caved inย to regulatory pressure and gave up on its higher-end ambitions less than a year later. - - - - - - - - -[Read Full Article](https://thedefiant.io/0l-libra-fork-fair-launch/) diff --git a/docs_old/archive/canonical/future_proofing_the_economics_of_blockchains_pt_3.md b/docs_old/archive/canonical/future_proofing_the_economics_of_blockchains_pt_3.md deleted file mode 100644 index 029fbdd2..00000000 --- a/docs_old/archive/canonical/future_proofing_the_economics_of_blockchains_pt_3.md +++ /dev/null @@ -1,146 +0,0 @@ -## TL;DR - - -Incentives are hard. There are many different stakeholders in a healthy economy and the needs of those stakeholders can be a moving target. Advanced mechanisms are employed to address the trade-off between clear rules and adaptive capacity. Polycentric programs with community wallets provide a means of voluntarily contributing to capex, while thermostatic security dynamically rebalances validator rewards based on validator count in order to manage opex. Furthermore, incentive alignment between network operators and end users is enhanced via two mechanisms: i) the introduction of slow wallets for validators which rate limit the availability to spend their rewards and ii) the introduction of an identity subsidy whereby end users may submit proofs of elapsed time to establish persistent identities and earn rewards (which do not have spending rate limits). - - -Part II discussed some principles and constraints of core protocol blockchain economic design. What follows is a discussion on what might reasonably be achieved at bootstrapping given the considerations outlined in the previous part of this article. - - -One caveat, we don't claim that these mechanisms are all necessarily stable or appropriate in steady-state, but that they are useful bootstrapping tools. The working assumption is that a viable network at maturity can articulate a transition to other economic guarantees. - - -### Polycentric Programs - - -A successful network needs builders, not just on day-one but throughout the life of an evolving, growing, improving network. The time and effort of builders has an opportunity cost and so must be rewarded. A network, however, is unowned which makes it challenging to provide to the builders appropriate incentives that are binding and results oriented. - - -Not every holder of the initial token supply is a builder. Similarly, not every builder is in a position to benefit the network indirectly, i.e. with cash. In ordinary startups this isnโ€™t a problem as the liquid investors - the capitalists - pay for the services of the illiquid builders. In the case of a network, a similar process could work if the builders hold tokens that are sold to investors, but there are obvious and notorious regulatory issues with this approach. - - -There is also a free rider problem. Since the network is unowned, each builder stands to gain from the investments of the other builders and may have an incentive to free ride, i.e. hold their own tokens letting others sell their tokens and make the necessary investments. The problem becomes worse as more people accumulate tokens. - - -A complete solution to both the free rider problem and the funding of public goods in a market setting is unsolved;solving it algorithmically onlyย [compounds the problem](https://kelsienabben.substack.com/p/algorithms-as-policy). Funding what rides the rails is a human activity. Algorithmically picking the correct moonshot application and the team to execute is an AI-complete problem. As such, there are many attempts to scale up this decision making that ultimately are doomed by the meta-game. - - -"The DAO" was the early example of a venture fund for "pirate equity" on the Ethereum chain. The story of the colossal hack is only remarkable, because it brought the designers of The DAO to the attention of regulators, which used it as the case-study for theย [SEC's shot across the bow at protocol developers](https://www.sec.gov/litigation/investreport/34-81207.pdf). Variations on this are to be avoided if your protocol is to have a moat against such "nation state attacks". Regulators haven't commented on funding protocol treasuries from pre-mines, founder rewards, and network taxes, but these mechanisms are likely too close for the comfort of many, especially the next generation of protocol builders who have yet to wade into the waters. Given the uncertainty and the potential downsides, most people will want a bigger moat. - - -So what are the enlightened self interested security guards of the early blockchains to do? Donations to programs run by individuals, businesses, or foundations are straight-forward. Soliciting contributions to do work on open-source projects is the bread-and-butter of many developers. As described previously, expecting early miners to do this post hoc is just a case-study in the prisoner's dilemma, and will lead to protocols'ย [capex being perpetually under-funded](https://vitalik.ca/general/2021/08/16/voting3.html). To get to a plausible solution we need to weigh some supply and demand-side effects. - - -On the demand side (early contributors wanting to contribute to programs which benefit the community), how do you get people to act in favor of their most virtuous preferences? Donations are prisonerโ€™s dilemmas that are vulnerable to free riding and to simple greed. Even if I value a project to produce a public good, I may try to free ride on the contributions of others -- a problem that gets worse if I donโ€™t value the public good at all. - - -On the supply side (the programs on offer), the question becomes how to prevent the things that blockchain as a movement is antithetical to: Graft, nepotism, exploits, and incompetence? Centralization of pools and discretion, such as premines to a foundation or network taxes to a group account, just seem to attract a type of Lord of the Flies standard of governance. Is it possible to have a market of programs, and do away with centralization and whitelists? - - -#### Optimizing Demand Side - - -You can encourage people to elect at a rate closer to the community optimum by making opt-in donations obvious, effortless,ย [automated, and highly visible](https://medium.com/commonsstack/automating-ostrom-for-effective-dao-management-cfe7a7aea138). Elinor Ostrom, the Nobel prize winning economist and political scientist, showed thatย [tolerable solutions](https://www.onthecommons.org/magazine/elinor-ostroms-8-principles-managing-commmons)ย exist for these kinds of problems especially in small, long-lasting groups where people can be monitored and initially gently chastised for norm-breaking with subsequent graduated sanctions. - - -#### Optimizing Supply Side - - -The supply of programs need not be fixed. Anyone should be able to create a program, and solicit donations - no matter the size. Like big-brand global non-profits who compete with each other for donor dollars, protocol programs are in a market. The most credible programs will attract the most funding. The programs with the most safeguards will also receive the most funding. A market for projects allows real world outcomes to form a feedback loop for which some projects continue to get funding and some die out. - - -Programs opting into participatory decision-making increase their chances of serving the market, i.e. the donorsโ€™ preferences. While it doesn't need to be included in the protocol, the protocol may offer smart-contract capabilities by which people can prove that they are a donor, such that the program can more easily poll the market for upcoming decisions, big or small. This is complex to do in the offline world, but in a smart contracts environment it's as simple as providing an on-chain "receipt" of donation to the account. Again, the protocol need not bind a program to do this, but making it readily available and there being simply one program adopting this could very well make it the standard by which other programs need to compete against in the market for donations. - - -A second boost to credibility of programs is giving them the ability to delegate the catching of fraud. Again, this is not possible with traditional offline foundations, but the transparency of a public ledger provides opportunities. A smart contract could be provided to programs such as a "secure wallet", where the program can elect a group which has supervisory authority in some very narrow cases. Typically on blockchain this is done with "multi-sig" wallets that require multiple signatories to allow a disbursement. However, electing signatories is an opaque process, and the technology to implement this is cumbersome In practice, most multi-sigs (some with billions of US dollars worth of assets) have fewer than ten authorities. - - -There's another more practical issue, that is, getting authorities to proactively sign every invoice is impractical. The process can be onerous when the goal is to prevent self-dealing and fraud. As an alternative, the program administrator should recruit the stakeholders to identify fraudulent transactions, i.e., slow them down to be scrutinized, and ultimately blocked. This could allow a larger group of stakeholders to observe, and they need not be fixed but may freely join or leave that role. More practically, the program may just elect the validator set operators (consensus nodes) to be in that role since they are ultimately the most trusted authorities on the network. - - -We think providing these tools to both consumers and providers of public good generation processes can create market micro-structures that fend off the prisoner's dilemma for a time. But this game relies on Ostrom's assumptions that social consensus can be enforced, and this does not scale. Scaling social coordination, however, is part of the magic of blockchain. In subsequent rounds of play, and with new players, stronger consensus can be encoded into the blockchain's policy. Modifying these games to create greater benefits for donors, ultimately incorporating guild-like tithes, or even a subscription of services, may be acceptable by subsequent cohorts. - - -Said differently: While regulators may not allow you to create binding games to solve prisoner's dilemma at genesis, with the right social norms this can be punted into a future round of the game. - - -Native token balances don't automatically solve your funding issues. Valuation of your dry powder is a vanity metric, given that actually using the funds can cause extreme turbulence in the market and thereforeย [needs to be considered carefully](https://uncommoncore.co/a-new-mental-model-for-defi-treasuries/). In this situation, proportions matter. Assuming that there is a healthy market for programs that are working to produce public goods, the next step is preventing the program ecosystem from becoming ransacked, not by fraud, but by a more stealthy actor: Dilution. - - -### Thermostatic Security - - -In designing a blockchain system, attention should be given to where the value flows. -How economic value is allocated depends on the rules of a system. In a competitive market with free entry, for example, suppliers compete prices down to costs and most of the surplus value flows to consumers. In a system with monopoly, the total value generated is smaller but a larger share flows to suppliers. - - -The biggest impact on the distribution of credits are the subsidies to node operators, after all, that is how the credits materialize in the first place and continue to be issued. In many protocols, especially early ones, much of the value flows to the miners in the form of block rewards (subsidies in the absence of transaction fees). The miners in turn compete to obtain that value and in so doing dissipate it in the form of server and electricity costs. Since much of the value per transaction (in the form of mining fees and subsidies) flows to suppliers, those blockchains aren't providing much consumer surplus in terms of transactions, although they can be very useful as a store of value. - - -Validators and full node operators verify that the transactions submitted to a blockchain follow the formal rules of the blockchain. Validation is critical to the successful operation of a blockchain, but it is an essentially mechanical or algorithmic procedure, much like verifying that a letter is appropriately addressed and stamped or that a contract has been signed. Validators should be paid enough to cover their costs and a normal profit, but there are few reasons to offer validators the prospects of extraordinary returns. Validation is like road maintenance, garbage pickup or web services--a critical service that should be prioritized, paid regularly, securely, and well. But, if you want value to flow to users of the service, validators should be paid based on the costs of supplying the service, not on the value of the service itself. - - -##### *The auction* - - -To avoid both over and underpayment of validators, and to distinguish validator payment from the fundamental properties of the system, the blockchain uses a simple and clear algorithmic process to converge on a fixed number of validators. The equilibrium number of validors is set so that it is at an optimal level for the validation of the network: large enough for competitive pricing and robust security, yet small enough to prevent value dissipation. - - -The key variable is the count of validators that have signed blocks within the last Y blocks. This moving average is data which is available to the core system's state machine. When the count of validators is below the optimal level, total validator compensation increases. When the count is above the optimal level, total validator compensation decreases. - - -![](https://siasky.net/TACPw_L307kSOzbii_ZrbZYQQJJzPzdbkn6ttjCXz96z8Q/graph.png) - - -Validators in this model are well paid but not overpaid. They are also paid equally, assuming the work is above a threshold. Based on the chart above, we propose that having, for example, over 100 nodes performing validation (in classical pBFT based consensus) has diminishing marginal returns to security, and therefore should not be overcompensated. - - -For this auction to work, it's important that it should be easy for validators to enter the market and also to exit. Ease of entry and exit and an adjustment process that changes validator compensation to keep the number of validators roughly constant around the optimal level together ensure that validators are always paid a price that reflects the true cost of providing validator services. - - -### Slow Wallets - - -Bootstrapping the network requires a careful balancing of two considerations. First, early contributors and adopters should be rewarded for their investments and efforts. Second, early contributors and adopters should not be rewarded such that later contributors are second-class citizens and thus should not be incentivized to โ€œpump and dump.โ€ A chain can balance these two considerations by rewarding early contributors and adopters, but locking them in until after everyone has had an opportunity to join, test and use the network. Thus, early contributors and adopters who may have outsized gains are not rewarded until the network matures. - - -There is no obvious reason the entirety of the credits for computation should be transferable between accounts. It is not like this for airline miles. It is also not like this for commodities, or real estate. If you are designing the credit to be durable and useful for computation in the future, or more, it is wise to keep in mind how the flows of those other assets work. Not all gold in the world can be transferred between accounts at a moment's notice. And how much of Manhattan's real estate by "market-cap" changes hands on a given day? The answer: A fraction of one percent. - - -At the start of a network, when an ecosystem is not yet developed, there are limited places to use your compute credits. There are limited smart contracts to execute, limited places to bond your credit for access to other benefits. So, while you can earn credits, and they are yours free and clear to use an unlimited amount in smart contract execution, there's not a great operating case for transferring them to other parties at the start of the network. - - -Speculation is one case, and there's nothing inherently wrong with that. What is a problem, however, is speculation by people with information advantages, people that have noย ["duty of care" to the platform](https://medium.com/token-engineering-commons/engineering-ethics-in-web3-18d981278018?source=linkShare-bdd1335dfbd-1636835251)ย (i.e. the risk of rug-pulls, and dumping); those actors make it a less trusted environment. - - -The network may choose to enforce limits on balance transfers in the code, for the simple reason of preventing a prisoner's dilemma, that is, while some parties may be happy to opt-in to slowly transferring their account balances, as soon as someone breaks the rule it causes a run on the bank. - - -Slow wallets should be opt-in, and not seen as a tax. The outcome an enlightened self-interested miner is seeking is: "I'll place my funds in a slow wallet, as long as others do so". To increase the incentive the collective can say certain activities on the network, ones that require greater trust for instance, need to be done by people with slow wallets, e.g. running validator nodes, can only be done by accounts with slow wallets. Additionally, this can be coupled with other ecosystem activities that create stronger consensus: The development programs (e.g., an engineering fund) can have a policy that will state that it will only pay out to individuals who have opted into having a "slow wallet". Thus, it becomes possible for the network to persuade the actors which have the most power to disrupt the economics of the chain to voluntarily opt into a lockup. - - -In many protocols we observe that locking schemes do, however, still tend to privilege early members (or investors with different term sheets) and those with information asymmetries. Two proposals can mitigate this: (1\) there should not be any lower "castes" of the unlocking regime; everyone has the same rule, and (2\) people get the same flat amount unlocked everyday (not on a percentage basis). - - -A reasonable lockup policy might look like this: Slow wallets are enforced by the state machine. If you want to be a validator, or otherwise access early features, those features will check if you have a slow wallet. You can, of course, keep an end-user wallet which has no limitations, but also does not access certain features. Transfer limits on slow wallets start at 0 and increase daily at a fixed amount (not a percentage, so whales do not have extra advantage). Every slow wallet has the same transfer limit schedule. - - -A possible variation on the above can be considered: The transfer limit schedule can be adjusted over time as transaction fees increase Thus, transferability matches the maturity of the network as measured by usage. This mechanism, however, suffers from a kind of problem: It will be very unpredictable, and have a low user experience. The user will not know what to do differently to effect the change. - - -Principally, and this should by now be obvious, the main benefit of locking is that it incentivizes early contributors to play the long game. All players over time should effectively be hearing the same instruction: Creating trains to ride the rails increases the long-term value of the network. Producing the public goods of the network is what makes your number go up. In other words, by limiting the opportunity to dump, locking incentivizes socially valuable greed. Extrinsic incentives are good when they incentivize actions in the social interest, that is, when they encourage investments that will increase the value of the network. Said differently, people who have bound themselves together for an extended period of time are incentivized to discover ways to cooperate (in and out-of-band) to produce and fund the application layer. - - -## Conclusion - - -We intend our principles to be a Schelling point to attract certain personalities. Not all of our designs are necessarily stable under all scenarios. In fact, we've made it clear that the donation game will eventually break down. We're confident though that these mechanisms will attract the people necessary to iterate in subsequent rounds of the game. People like you, since you've read this far! - - -The warning signs of the past mistakes are loud and clear for public infrastructure. To return to our prior narrative, railway profits were eroded by competition with the interstate highway system and air travel. This brought the Pennsylvania Railroad company to its knees. The lesson is: Donโ€™t fall in love with instances of public goods, but do build on them, and plan for the next century. - - -We are playing an infinite game, not a finite game and the only way to win an infinite game is to keep playing. Carpe diem โœŠโ˜€๏ธ - - -ย  diff --git a/docs_old/archive/canonical/future_proofing_the_economics_of_blockchains_pts_1__2.md b/docs_old/archive/canonical/future_proofing_the_economics_of_blockchains_pts_1__2.md deleted file mode 100644 index 2cfeb4b3..00000000 --- a/docs_old/archive/canonical/future_proofing_the_economics_of_blockchains_pts_1__2.md +++ /dev/null @@ -1,158 +0,0 @@ -## TL;DR - - -A transformation in society is taking place and layer-1 computational blockchains are the substrate. While the economic fortunes of layer-1 computational blockchains may wax and wane, the goal of the collective behind them should be to transition their economic stake from the infrastructure layer into the application layer. This leap will take time, and most blockchains will not make the leap. Coordinating the labor and care that goes into the work of producing a blockchain that can make the leap is not trivial. We propose some principles so that blockchains can successfully cross over to that shore when the day comes. - - -## PART I - The Opportunity - - -Crypto is an experiment in digital scarcity. New digital resources have emerged, such as coins, tokens, NFTs and more. We're here to talk about layer-1 blockchain network "gas" coins. Through one lens, the liquid and instant settlement of these resources makes them look like cash. From another perspective, they look like deeds, rights, memberships, or even a cooperative business that defies our legal definitions of companies and partnerships. More generally, gas coins mediate access to one of most exciting social technologies in recent memory: Smart contracts. - - -The computation needed for smart contracts is not orthodox computing power. Credibly neutral replicated state machines are the technical artifacts that are required and currently the quantity demand exceeds the quantity supplied. Current crypto economics are not necessarily well configured. - - -We're not here to wax hyperbolic about the power of smart contract platforms but, for new entrants, suffice it to say that the blockchain as a ledger is only one facet of the innovation. At the baseline, smart contracts allow for the composing of many interactions of value, both native and non native to the digital realm. The collective ingenuity of workers in this space is engaged by the possibilities of programmable monies, firmly binding agreements, durable memberships, and all manner of automation of value. Beyond the horizon are even more experimental use-cases: Prediction markets, new forms of voting, new forms of identity and pseudo-identity, the integration of the real world and virtual reality in the metaverse. More generally, itโ€™s obvious that the world is moving online and will continue to do so. The power of blockchains is that they let people create secure property rights and identity systems that amplify the power and utility of the online world. - - -The early experiments in this space (e.g., payments, decentralized finance, asset tokenization) are eachย *trillion*ย dollar markets; this certainly explains in part why the crypto space has boomed. However, the financial exuberance around blockchains contains the seeds of its own destruction. The promise of the blockchain will be fulfilled precisely when and if blockchains are cheap, abundant and commoditized. The froth we see in the market for blockchains is based on the assumption that these infrastructures can capture the value the ecosystem provides; but the ecosystem will produce tremendous value only when the infrastructure becomes a global public good accessible to everyone at low cost. The cheaper the rails the more value will ride the rails. This may appear paradoxical, but the implication here is that the rails don't reflect the value of what is riding upon them. - - -Layer-1 platforms of the next decade will begin to see more acceptance, but they will also see challenges to the unit economics of providing the compute resource. This article highlights what some of those challenges may be, and how the community which holds native gas coins - the "digital asset collective" - can future-proof the economics of the blockchain. - - -### Cautionary Tales From Infrastructure Businesses - - -Not all blockchains will be successful. While transformative, a number may end up being more staid than they appear at the moment. There's a risk that the colorful and exciting vision of the metaverse escapes the actual economics of operating the blockchain infrastructure. Indeed, the most successful blockchains will likely become utilities. - - -Infrastructure businesses often boom early but over time tend towards steady but normal profit levels. In the United States, the opening of the Baltimore and Ohio railroad in 1827 began a boom in railroad construction that would last for over 60 years. The railroads were tremendous investments, but their real value was in opening up hundreds of millions of acres of farmland, thus lowering the cost of food and creating national sales markets which let every good enjoy economies of scale. As railroad construction boomed, however, competition eroded railroad profits and value was transferred to consumers and bystanders. As the railroads became infrastructure, the growth in value shifted towards those who were able to leverage the structure for growing businesses. In other words, as the railroads became infrastructure, you didnโ€™t want to be a rail operator, you wanted to be Sears, Roebuck and Co. - - -You may think financial "rails" are different. They arenโ€™t. You may think you have time, after all, the railroad bonanza lasted for a century. You donโ€™t. The rate of change is speeding up. - - -There is lots of money to be made in the heyday of an infrastructure play, but the opportunity can vanish fast, especially in the age of digital abundance. By way of comparison, the window of opportunity for Internet Service Providers in the early 90s shrunk by a factor of 10\. What took 60 years for railroads took 6 years for ISPs. When the government's Arpanet opened up access to the general public, a new land rush took place. Everyone who was operating bulletin board services began jockeying to provide dialup access to the Internet. The hottest skills on the market were not only software programmers, but also electrical engineers for wiring up banks of telephone switches. Real estate near points of access to phone exchanges went for premium. - - -Where are the names of the early ISPs today? Your equity in Compuserve, The World, Prodigy, or Earthlink did not earn you any stake in Google, Amazon, or Facebook. Over the next decade, the telecom engineers did not receive the same life-changing stock options their web developer peers did. The one notable exception was AOL, which avoided obscurity by buying Time Warner, and eventually being gobbled up and then spat out by Verizon, an infrastructure company. The AOL story is noteworthy because they tried in many ways to make the leap from the infrastructure layer and capture the application layer (with the ultimately misguided tactic of creating a walled garden) . - - -For digital asset cooperatives to make the leap from billing for ledger access to providing consumer surplus, the economics of the blockchain of today need to be anchored on solid economic principles. The blockchains that succeed will be the ones that transfer the most value to the structures that build on top of them. Blockchains as infrastructure means creating user experiences where the blockchain technologies become transparent to the user. The boom may not last, but it can be the foundation for continued growth and utility. The railroads, after all, never went away and continue to be critical to the world economy. - - -In the coming decade blockchains will see a number of changes and they will cement their place in society as infrastructure. The value of access to the ledgers, and the flows to capital, will increasingly resemble traditional economic assets. Like dialup networks, transaction fees on blockchains will fall to negligible amounts given advances in high-throughput blockchains (which will become commodities because of open source software). - - -Your digital asset collective may want to be more than a reliable infrastructure business. Yet capturing value on the application layer of blockchain is less than obvious. The (regulatory compliant) mechanisms don't yet exist, but the collective can future-proof its layer-1 economics to create optionality to escape a lackluster infrastructure fate in a world where theย [fat protocol thesis (an idea that enterprise value accrues into a vertically integrated settlement layer) proves hollow](https://www.usv.com/writing/2016/08/fat-protocols/). The value is likely to be modular and decentralized, not monolithic and bundled. - - -## Part II - Principles for Future-Proofing Your Blockchain - - -For a time, exuberance will mask the realities, but eventually, the community of holders of a chainโ€™s native asset will need to make a leap. When transaction fees fall off the cliff, the collective will need alternative business revenues; simply selling access to the ledger will no longer produce attractive returns. We think the blockchains that survive the coming crisis will be built on the following principles. - - -### Don't Eat Your Seed Corn - - -In most protocols we observe a confusion between capex (capital expenditures), and opex (operational expenditures). Payment for security in the moment, an operating expense, is not equivalent to investment in future security, a capital expenditure. - - -To illustrate, imagine the blockchain as a physical notary business. As is the case in many countries in South America and Europe, private companies can acquire a concession to store and provide access to contracts, land records, birth certificates, etc. The business has a finite budget. It can invest in security guards to stand outside the entry, or invest in physical vaults and computer systems. As with any business, there are strategic considerations and ultimately it will have to employ a mix of both outflows. - - -Paying security guards is a certain kind of recurring outflow - an operating expense. The costs appear in the same part of the income statement as expenses like phone systems, administrative staff, executive travel, etc., that is, activities (expenses) deemed necessary for the business. Opex should not be confused with outflows of capital made for investment purposes; that is capital expenditures. Capex is different (for example it doesn't even appear on an income statement); it's part of the value of the company (balance sheet) which is transferred between assets. You are trading the cash assets of today for future productive resources, e.g., by investing in new factory machinery, delivery vans, document vaults, etc. - - -The capex/opex distinction is not an accounting gimmick---confusing them is the downfall of many a business tycoon. No amount of paying for security guards would obviate the need for an investment in a new vault. The owner of the notary needs to set aside cash, equity, debt - whatever instrument - to pay for the capex. Startups a la Silicon Valley, pay for initial capex (acquisition of talent, software, R\&D) with equity. However unfair, the labor market does not often make errors, and the people who accrue the most equity from the market are leaders and engineers, not security guards. - - -In blockchain, paying for moment-to-moment security is done with transaction fees to miners/validators. In the absence of these transaction fees, there are subsidies to cover for the market cost of providing network security, lest the network risk losing its perceived integrity. - - -For much of the first decade of blockchain, the future investment in the protocol was done on the basis of the "enlightened self-interest" of the early security guards of a chain. The logic goes as follows: The security guards amassed such a large equity in the notary business, that they now were the primary stakeholders, and as such had the incentive to reach into their pockets to recapitalize the notary, who had gone delinquent in its capital investments. Paying security guards in the hope of them later contributing to paying for your vault is circuitous and risk-prone. If the coins are readily and easily tradable, the dominant strategy is to dump and move on to the next chain when you notice capex being under-capitalized. - - -A protocol needs to be careful that the opex does not eat up the capex. The more cash you spend on opex the less you have for capex. The equity you issue to security guards dilutes the engineers and that's before we consider intergenerational fairness. Time compounds these losses: When dilute your brother with a drop, you dilute his grandchildren in buckets. - - -We are not trying to be obtuse or sanctimonious, but rather point out a structural problem that could prove fatal to protocols that mis-invest their cash flow in a philosophical concept, rather than in building useful applications. A new protocol seeking to be lasting and fruitful needs to have a sustainable long term investment model. While solutions are difficult to come by, meaningful experiments are taking place. - - -A number of protocols approached this problem by dedicating funds (or "founder rewards") to "foundations", but this then started attracting regulatory scrutiny. A later variation saw some chains implementing "decentralized treasuries" to make decisions on work that needs to be done (e.g.,as in Tezos, Cosmos, et al). While there are still regulatory overhangs here, and a trend toward bureaucracy, this is directionally the right move. - - -Digital asset cooperatives need to stand firm and preserve the capex games they create. Issuing new coins -- like issuing new equity -- is an invisible diluent, and it mostly hurts those who are not minding it. There will always be relenting and incessant requests to spend more today on opex. Don't confuse your opex for capex. Don't eat your seed corn. - - -### Produce consumer surplus - - -Generally speaking, blockchains should aim to maximize consumer surplus; that is, the difference between the value a consumer places on a good and its price. Maximizing consumer surplus means increasing the value of a blockchain to consumers and keeping prices low so that the bulk of the tremendous potential from blockchains flows to consumers. Ensuring that gains flow to consumers requires competition and a blockchain design that doesnโ€™t create artificial rents or bottlenecks that can be exploited by rapacious actors. - - -Itโ€™s widely acknowledged that the current payment infrastructure is slow and expensive, especially for international transactions. In contrast, a million dollar transaction can clear across a blockchain in minutes at a price of pennies. The claim is true, but it rings false when transaction fees on popular blockchains are high and variable, with spikes of $10, $100, or more, not uncommon for a single transaction. - - -A usable blockchain integrated with the real world must produce fees that are low. Low and consistent is ideal. Low and variable is ok. High and variable, however, is a problem. This is both a user experience and a negative network effect problem. - - -Consumer surplus is maximized when every consumer who values a good at more than its cost is able to purchase. In a competitive, well-functioning market, price (P) approaches the marginal cost (MC) of production. Consumers who value the good more than its price purchase the good and when P\=MC. It follows that every consumer who values the good more than its cost purchases the good. If the price were above MC, too few consumers would purchase and if the price were below MC (say because of subsidies or non-price allocation) too many consumers would purchase. P\=MC is the ideal. (There are, of course, well known exceptions to deal with cases of externalities and large fixed costs. We focus on the base case for clarity.) - - -Suppliers would prefer P\>MC, which happens when markets are monopolized or otherwise broken. The US medical system, for example, is dominated by rents and bottlenecks that push P\>MC and which have been exploited byย [the Shkrelis of the world](https://www.nytimes.com/2015/09/21/business/a-huge-overnight-increase-in-a-drugs-price-raises-protests.html). US housing markets are similarly broken by zoning and regulations that prevent building even in places where prices are well above the costs of production. - - -To fulfill their promise, blockchains must onboard billions of people into a new, lower cost financial system (as a first step!). Onboarding billions of people will happen only when P\=MC, that is, when the price of using a blockchain falls to its true cost of production. To get there, blockchains have to be designed to operate at their maximal technical limits and not be throttled back in order to create rents. Blockchains must also surface information and not incentivize the creation and exploitation of information asymmetries. Everyone must have access to a blockchain on an equal footing. - - -In addition to keeping prices close to marginal cost, blockchains should be designed to increase value to consumers. Blockchains, as with other platforms, can be designed to maximize eyeballs, or information collection, or surveillance--techniques which can increase producer profits. In the short run, profits can attract investment and customers, but in the long run, a blockchain built for producers leaves a dissatisfied public only slightly better off than before. - - -### Maximize the correct resource - - -Blockchains have attracted attention because the sector has produced outsized financial gains. These gains, however, are merely the promise of future value. As the technology matures, financial gains will diminish and gains to consumers will grow. We want to build the future in which consumers devote an ever-larger share of their time and contribution to the globally connected online world. - - -Security and decentralization are important for the bootstrapping and running of the network. As we put it earlier, the utilities must work reliably and we want a six-sigma blockchain. Most of todayโ€™s crypto industry revenues, however, flow to trading and mining as built-in economics, which leaves little room for rewarding the builders who make the things people love. We want to create organic incentives that benefit the builders and the users -- the economic actors rather than the security and rule enforcers. - - -A blockchain collective should aim to allocate funding to the building of an open and expressive space where people have the capacity to organize themselves around their shared interests, activities, outcomes, etc, and instantiate that as software, games, and economies. To make things, people have to choose to invest their labor in a protocol, and we want the protocol to be able to reward them for that labor and investment (rather than a venture fund which owns their equity, whereas the protocol is a community that generates public goods). - - -Whether one calls it the global village, cyberspace, or the metaverse is immaterial. Moving forward, the key idea is to assemble and reward the people who generate value in the new world. - - -Financial incentives are one method of attracting time and attention but are not the only nor always the best method. Paying fruit pickers per fruit will increase the number of fruits picked per hour but the fruit may be picked too early or too small. Thus, even in a simple task such as fruit picking, financial incentives must be combined with other methods of encouraging productivity such as monitoring or profit-sharing. - - -The key problem with financial incentives is that you get what you pay for but what you can pay for is not necessarily what you want. As a result,ย [financial incentives must be used with care](https://vitalik.ca/general/2021/09/26/limits.html)ย especially for complex, multi-dimensional tasks where monitoring and measuring are difficult. Said differently: algorithmic and programmatic distributions are very unlikely to be maximizing the correct resource. - - -### Integrate with the world - - -It was natural for early innovations in the digital space to position themselves against the world. Most famously, John Perry Barlow offeredย [A Declaration of the Independence of Cyberspace](https://www.eff.org/cyberspace-independence)ย in which he declared: - - - -> Governments of the Industrial World, you weary giants of flesh and steel, I come from Cyberspace, the new home of Mind. On behalf of the future, I ask you of the past to leave us alone. You are not welcome among us. You have no sovereignty where we gather. - - -For better or worse, Barlow was wrong. Governments have power even in Cyberspace because people want to integrate their real lives and online lives. Similarly, if a blockchain is to remain relevant, it must integrate with the real world. The metaverse, so to speak, is not only a digital simulacrum, but also an online world synthesized with the quotidian. Integrating with the real world means considering the existing rules of the road. - - -Designing for the environments people live in is a question of user-experience. With everything UX, there are tradeoffs. While securities laws need to change to keep pace with new technologies, like it or not, the regulators are an agent in your game. While it is possible to design games that flaunt regulators, this exposes less adventurous users -- the next billion -- to unnecessary duress. Following existing law, especially US law, restricts some of the economic mechanisms which would be effective. The absence of ambiguity however should not be seen as a limitation; on the contrary, it should allow the protocol to be practicable and useful to future denizens of the metaverse. This is not an admission of defeat, it is actually an aggressive stance, positioning for exponential growth. - - -For the same reasons, economic mechanisms must be understandable. Mechanisms (i.e., the rules for which rewards are given) are what guide users, validators, and investors across language and other barriers. Good mechanism design incentivizes the crowd to "do the right thing". People need to know what activity they are to do, and what they should expect as a result. As is well documented in cognitive science research, humans are limited in their ability toย [navigate optionality](https://thedecisionlab.com/reference-guide/economics/the-paradox-of-choice/), they place aย [lot of value on labels instead of mechanics](https://journals.sagepub.com/doi/abs/10.1177/0146167204264004), haveย [non-obvious responses to price information](https://en.wikipedia.org/wiki/Forced_compliance_theory#Festinger_and_Carlsmith), areย [notoriously bad at planning for the future](https://www.nber.org/bah/2016no1/how-biases-affect-retirement-savings),ย [etc. etc.](https://en.wikipedia.org/wiki/Cognitive_bias#List_of_biases)ย Given that context, if your incentive model doesn't match peoplesโ€™ intuitions, you should expect erratic, random behavior from the majority of your players and exploitation by the minority of informed insiders. - - -Sometimes the best incentive is to make doing the right thing easy and obvious. - - -ย  diff --git a/docs_old/archive/canonical/libra_liberated.md b/docs_old/archive/canonical/libra_liberated.md deleted file mode 100644 index 238d49ab..00000000 --- a/docs_old/archive/canonical/libra_liberated.md +++ /dev/null @@ -1,157 +0,0 @@ -There once was a community that wanted a blockchain. - - -Its members wanted to be a part of the coming transformation of society. - - -This is the story of how they got their chain, and why you might want to join them. - - -## The Opportunity - - -Decentralized architecture, coupled with the power of smart contracts, is a once-in-a-century opportunity for society: It is far more than programmable money, it is a canvas for valuable human interactions. - - -The opportunity is materializing now. While the common narrative is that it is still โ€œearly days,โ€ the reality is that the value of individual crypto networks reach toward, and even surpass, one trillion US dollars. As such, the budgets to enter this space and stay relevant are astronomical and ever-increasing. It is possible that the leading platforms of today, and their stakeholders, will permanently dominate the space. And that's even before the roll-out of corporate and national blockchains. - - -It can certainly seem like there is not much low-hanging fruit for anyone that has been left out of this story so far. The window to build a new meaningful network is closing. - - -But there is one unusual (perhaps unique) opportunity left. - - -## The Game - - -If you're new to the blockchain space, you will soon learn that the technology is not \*the product\*. The product is the game the technology enables. - - -The players, the interactions, and their outcomes, are the design elements of blockchain. And there are many ways to craft gameplay. - - -Blockchain networks inherit an ethos from their creators. Communities -- and their norms and goals -- precede the technological artifacts of a chain. Perhaps then it is not surprising that many groups design their game to reflect existing patterns and myths. You can, for example, design a blockchain where the economic game resembles a corporation, maximizing profit for winners with exit strategies. Or you can design what is called an \*infinite game\*; a framework that perpetually sustains new players, new rules, new settings, and new possibilities. We think infinite games depend on people opting-in out of excitement, and not out of lack of alternatives, or fear of missing out. - - -**We wanted to create a game that anyone could play; a game everyone would want to keep playing.** - - -Before Silicon Valley built Robinhood the company, there was Robin Hood the legend. The story is set in a kingdom whose king is absent, off fighting distant crusades. The young prince, a usurper of power, has occupied the void and turns ordinary life into a hopeless maze. In the depths of this unfortunate situation, a group of individuals arise who take exception to the status quo and attempt to rebalance power and equity. - - -This story is timeless. It has a villain who we all recognize. The usurper is familiar across centuries; it changes in name only: sovereigns, incumbents, bureaucracy, big-tech. - - -The legend lives on not because a single player wins, but because the circumstance of inertia, subjugation and injustice recur. The winner is the Robin Hood game itself. Humanity perpetually plays it; an infinite game.ย **The rules of play are simple. You can take from authority, if you give back to your people. You should aim to do well for yourself, whilst remaining a fun-loving rascal.** - - -## Snatch the jewels - - -In June 2019, something curious happened: A consortium of the most powerful financial and technology houses on the planet banded together to build a new, global cryptocurrency, prompted in their efforts by Facebook. They preached equality and financial inclusion, with assurances that decentralization of this network was just a matter of time. - - -As the project progressed, things began to change and a grimmer reality set in. What began as a blockchain-powered digital currency aimed to improve financial inclusion became a payment network governed exclusively by incumbent corporate actors and enterprise compliance requirements. - - -Behind the scenes, away from the growing controversy about money and regulation, a talented group of engineers was creating breakthrough technologies. To make this planned digital currency work, for the scale of billions of users, they built a bejeweled blockchain. It was a blockchain as fast and secure as anything in the market. Most importantly to this story, they released that code under an open source license for others to modify and remix. It was called Libra (later renamed, Diem). - - -The situation created an inherent contradiction. While the code was open sourced, the network that ran the code was fundamentally closed and controlled exclusively by a private consortium of big brand actors who were required to provide large pools of capital for membership. - - -**We didn't think that was right, so we jailbroke Diem.**ย We forked the open-sourced Libra code back in 2019, and kept up with the changes under its new name, Diem. Since then thousands of developer hours have gone into making that code ready for release. We are now ready to share it with you. We call it 0L, not only the 0th Libra-consensus blockchain, but also an open Libra network. - - -**0Lโ€™s vision is to turn that jewel of a blockchain, and the network which it instantiates, into something that is open, permissionless, participatory, and egalitarian.** - - -This was hard work, and took two years to complete. The job was far more complex than simply making a copy of source code. The original project was designed to be run on a private network with a tightly controlled set of economic incentives that vested power and economic return solely in the network operators. A new economic model had to be designed, a new Sybil resistance algorithm invented (Delay Towers), and a number of related mechanisms had to be adjusted to optimize performance under these new conditions. The result is thousands upon thousands of lines of new code designed to make that blockchain fit for use in a public network. - - -## Genesis - - -Just a couple weeks ago, on October 27th 2021, a new network genesis took place. It is a blank canvas. This blockchain network is maximally compatible with Diem, but capable of permissionless innovation and decentralized economies. - - -There are millions of people working in crypto today. We need billions. To get there, the protocol must be safe for use, and avoid a variety of attack vectors. Stated differently: We need to protect the game. - - -Paying homage to Bitcoin, 0L went back to the basics: There is no pre-mine, no corporations, no investors, and no permission. - - -* We chose to stay close to Bitcoin's model. -* There's a foundation which pays for Github hosting, and does nothing else. -* Early miners didn't take any VC money. -* 0L doesn't use proof-of-stake. -* We skipped the DAOs controlling a treasury. -* Coins don't buy shareholder votes. -* There was no ICO, nor an airdrop. -* There were no side-deals with exchanges. -* No market-making. - - -If your instinct was to say a network without those activities is not viable, you are squarely wrong.ย **It is 0L's superpower. No one should be looking over their shoulder at governments because they participate in a protocol.** - - -## Do well - - -If you ever wonder what opportunities are left for entrepreneurs in the world, we urge you: Look for the \*negative space\*. - - -Companies and governments will not do - or cannot do - all the things we want from life. In this void lie an endless amount of problems at the intersection of information, economics, and social coordination. This is all of humanity's unfinished work; a vast negative space which the markets and sovereigns have weak dominion over. - - -What are the things you expect from the government but can't get? What then do you need to acquire from companies but are inadequate? Depending on where you live, making progress in healthcare, education, justice, news, or voting, can feel hopeless. - - -Hope comes to us in the form of new economic games we can play because of blockchains. Blockchain offers truthful notaries, durable memberships, transparent markets, and binding agreements. Modern economics provides new mechanism design gadgets: Prediction markets, Quadratic Voting, Dominant Assurance Contracts, Crowdsourcing, Curved Bonding, and things yet to come. The true potential is yet to be unlocked, to be imagined and instantiated by you and this growing community. Today, we merely lay a foundation upon which you can build. - - -This is the entrepreneurial blue ocean of our time, however solving these issues may not lead to viable startups. That's perfect! This is the domain of \*the thing that comes after companies\*. We are all so early that there is not yet a good name for it. Web3 and the multiverse are still mere shadows flickering on the wall. - - -Don't try to replace companies, they are good at what they do. Donโ€™t pick fights with nation states that provide for their citizens, however inefficiently. Instead, go do the things they cannot.ย **Mechanism designers are the new entrepreneurs. Design the negative space, and become the social architects in the era of blockchains.** - - -## Do good - - -We live in a society, and we must be wise towards each other. - - -Since 0L is based on an existing open source license, and it arrived to us freely, all members must think critically about the value inherent in the technology, and the potential which it can produce. How should we distribute that potential? On 0L there's wide latitude to craft a better distribution game \*because\* the network is unencumbered by the pressures of generating a return to corporate and venture investors. - - -0L makes it easy for you to decide if and how to share your mining rewards. Using auto-pay, all node operators have the option to donate a meaningful portion of their nodeโ€™s earnings to support a variety of programs, so that donating activities in the community (and beyond) is frictionless. You can auto-pay to your team, to your tribe, or to a cause. In our experimental network, we observed node operators donating on average over 50% of their mining rewards. This was not just toward the sustainability of the blockchain (engineering programs), but also humanitarian programs and baskets of high-impact nonprofits. - - -## Underdogs have more fun - - -Among other things, Bitcoin is a weird and wonderful prank on sovereign power. There are many other powers-that-be which deserve the same treatment by a merry band of rascals. - - -Jailbreaking Libra/Diem was not a quick win. The fun started almost three years ago by many volunteers coding and puzzling over the technology. We successfully ran a real-world experimental network for nearly a year. We could have launched with that network, and we could have done a pre-mine, but we didn't because it's just less fun for everyone. We sunsetted the test network, and started a blank gameboard with you in mind. - - -With that done, the real fun can begin. Your first mission? Take the prince's jewels. - - -Download an early beta release of \*Carpe\*, a light miner that you can run on your laptop and make coins. There's nobody you need to pay to get coins, no company to ask permission from, and most importantly: No one that can take this back from you. - - -[https://github.com/0LNetworkCommunity/libra\#readme](https://github.com/0LNetworkCommunity/libra#readme) - - -The future missions are entirely up to you. Crypto are the in-game points for the real world. - - -**Game it, play it, carpe diem โœŠโ˜€๏ธ ,** - - - -> - Otto diff --git a/docs_old/archive/canonical/technical/delay_towers_pt_0.md b/docs_old/archive/canonical/technical/delay_towers_pt_0.md deleted file mode 100644 index 20c4b4b2..00000000 --- a/docs_old/archive/canonical/technical/delay_towers_pt_0.md +++ /dev/null @@ -1,84 +0,0 @@ -## A high\-throughput chain with a fair launch - - -## TL;DR - - -A fair launch of a high\-throughput layer\-1 blockchain is happening. - - -You won't need to buy anything or otherwise pay a centralized organization for access. The goal is to create a new standard in blockchain bootstrapping through Delay Towers. - - -There's a new layer\-1 chain that wants to exist. It wants to have these characteristics: - - -* High\-throughput -* Faster finality time -* Fair launch -* Establishing a persistent identity -* Permissionless access -* Engender decentralization -* Regulatory certainty - - -Centralized launches of Proof of Stake networks are an unsatisfactory strategy for bootstrapping a community\-led public good. No disrespect meant to projects that have launched in such a way, there was just no credible technical alternative, possibly until now. - - -## The Tradeoff - - -If you are looking for a blockchain with fast finality, you are likely evaluating a derivative of the Byzantine Fault Tolerance (BFT) consensus system. Research on BFT consensus has progressed from designs requiring multiple rounds of communication to finalize a block, up to the latest breakthroughs of "consensus linearity" and "pipelining", which produce systems where the throughput is limited only by the network connection latency. - - -To achieve the benefits of BFT, the networks require establishing identities for validators to participate in the consensus protocol. Currently, most blockchains rely on either of these: Proof of Authority (PoA) for private consortia and Proof of Stake (PoS) for permissionless environments. PoA lacks credible neutrality due to centralized validator membership control, and PoS suffers from a lack of diversity of participants and high inequality while raising numerous significant regulatory concerns. The novel Delay Towers are an alternative mechanism to establish persistent identity in permissionless environments. - - -## Delay Towers - - -Delay Towers are a Proof of Elapsed Time to build persistent identities. Drawing inspiration from the paperย ["Sybil\-resistant network identities from dedicated hardware"](https://docs.google.com/document/d/1eRTAe3szuIoZEloHvRMtZlrU7t2un4UVQ8LarpU3LNk/edit?usp=sharing)by Dominic Williams, the proposed design extends the idea of "puzzle towers" withย [Verifiable Delay Functions (VDFs)](https://eprint.iacr.org/2018/601.pdf)VDFs are cryptographic primitives for providing a guarantee that a lower bound of time has elapsed. - - -In this protocol every node in a network has a Delay Tower, which is composed of linearly chained proofs. A chain of Delay Tower blocks produces a guarantee of cumulative work done by a node in the network. Each proof extends from the previous one (using one proof as the preimage to the next block), building the tower "higher"; creating a series of sequential proofs of work. Unlike traditional Proof of Work puzzle algorithms that are parallelizable and probabilistic, "mining" a Delay Tower is sequential and deterministic. Since VDFs cannot be parallelized, they do not benefit significantly from alternative hardware such as GPUs. The delay towers enable persistent identities by providing a permissionless and non\-forgeable identity for miners. - - -Delay Towers establish an identity for miners, and can be used as a metric to quantify a node's commitment to a network, and subsequently rank it for the purpose of choosing inclusion in the validator quorum at every epoch. This is achievable, in part due to a significant cost to participate in the network. One has to dedicate resources to build their towers and a high exit penalty to recreate their identity due to lost work. And the cost goes up over time as all nodes continue to extend their towers. - - -It is not feasible to apply infinite money or resources to forge a tower, the time taken cannot meaningfully be reduced. A forgery will take approximately the same amount of time as the original. As such, a Delay Tower becomes a permissionless and non\-forgeable identity that is fast to verify; valuable in its own right. - - -## The Experiment - - -An experimental network ran successfully for nearly 1 year without interruption. It used a Delay Tower protocol for assigning consensus power for a modern BFT blockchain architecture. This is the first publication in a series of articles which will summarize the protocol, and discuss the attractive features that were observed in the experiment, such as: - - -* Providing persistent identity which aids in Sybil resistance in BFT consensus. -* Offer a more diverse distribution than usual, to anyone with minimal computational resources. -* Levelling the playing field, with a linear function the advantage of the miners at genesis goes down over time. -* With minimal computations and no wasted cycles, delay towers offer an eco\-friendly alternative to PoW approaches. -* Offering a mechanism to bootstrap a BFT network without selling tokens (ICOs), venture\-backed foundations, or airdrops. - - -## To be continued - - -Instructions for mining the new chain will materialize in the coming weeks.ย  - - - - ---- - - -## Full Series - - -1. [A high\-throughput chain with a fair launch](http://openlibra.blog/2021/11/01/delay-towers-part-0/) -2. [Puzzle Towers for BFT](http://openlibra.blog/2021/11/05/delay-towers-part-1/) -3. [From Puzzle Towers and VDFs to Delay Towers](http://openlibra.blog/2021/11/08/delay-towers-part-2/) -4. [Implementation on BFT](http://openlibra.blog/2021/11/12/part-3-a-delay-towers-implementation-on-bft/) - - diff --git a/docs_old/archive/canonical/technical/delay_towers_pt_1.md b/docs_old/archive/canonical/technical/delay_towers_pt_1.md deleted file mode 100644 index 19136dc4..00000000 --- a/docs_old/archive/canonical/technical/delay_towers_pt_1.md +++ /dev/null @@ -1,120 +0,0 @@ -## Puzzle Towers for BFT - - -## TL;DR - - -Puzzle towers may offer a new Sybil resistance technique worth exploring for permissionless environments, especially during network bootstrapping. They offer a glimpse into what a different game for starting a diverse BFT network might look like. However, without modifying the type of work done in a puzzle tower, the advantages given to current PoW miners would make the proposal a non-starter. Alternatives to traditional PoW will be discussed in the following article. - - -## Context - - -Blockchain systems can leverage Byzantine Fault Tolerant (BFT) protocols to provide high throughput (transactions per second) and faster finalities. Currently, proof of authority (PoA) and proof of stake (PoS) are widely used Sybil resistance mechanisms for BFT networks. While PoA systems lack credible neutrality (due to permissioned access to the validator set being managed by centralized membership providers), PoS systems are permissionless with open access to the network. PoS systems have a well-defined parameter space and protocol designers are tasked with tuning parameters to match a community's requirements and culture. - - -Without going into depth, it's worthwhile to summarize a few challenges of PoS networks. - - -### Distribution of tokens - - -How does a PoS blockchain genesis happen? If you strictly apply the logic of PoS, a stake must pre-exist before the network. Without getting into the notorious regulatory issues associated with token issuance, the manner in which the initial distribution occurs has the potential to threaten the credibility of a neutral smart contract execution environment. - - -Allocation of stake always has bias (which could contribute positively or negatively to the community's goals). BFT networks also have biases: High validator node requirements and upper bounds on quorum sizes often tend towards monopoly. And that's before considering the compounding of interest on stake, which likely only exacerbates the bias. - - -### Diversity of stakeholders - - -A public good smart contract system must aim to be neutral. It's difficult to imagine neutrality without diversity. This raises the question: How can one ensure diversity among stakeholders in the network? - - -The predominant issue with achieving a plural and diverse set of stakeholders is the technical overhead necessary to participate in a new blockchain. Most platforms' stakes are typically reserved for technologists and venture capitalists.The general public and many institutions are left out at worst, or merely second thoughts at best. Networks requiring high capital commitments, i.e., you must buy a stake, make those networks inaccessible to many. In some limited situations weรขโ‚ฌโ„ขve seen institutions "loaned" the necessary stake, or developers granted stake (by a centralized promoter) as part of a testnet program, but such mitigations tend to be marginal in impact and fall short of open, equitable access. - - -With this context on PoS and industry practices, let us revisit BFT networks and see if we can address these challenges. - - -## Byzantine Fault Tolerance (BFT) - - -We need the briefest background on what we mean by BFT. Leslie Lamport published the Byzantine Generals Problem in 1982, laying the foundation for multiple breakthroughs in distributed computing over the past four decades. The goal of BFT protocols is to solve the Byzantine Generals problem, i.e., reach consensus among a set of nodes where some of the nodes might be dishonest. The Practical Byzantine Fault Tolerant (PBFT) protocol established a standard for BFT protocols running in production. We've seen multiple variants of PBFT developed by optimizing parameters, such as rounds, to reach finality and messages broadcast. For instance, the improvements on the aggregation of signatures with the BLS scheme allowed us to reduce the number of broadcasted messages. Protocols such as HotStuff progressed BFT to consensus linearity wherein an agreement on a message is reached in a single round. Pipelining of blocks in HotStuff guarantees the finality of the proposed block by the third block following the proposed block. These advances in consensus are highly desirable and future blockchains will likely continue to use variations on these protocols. - - -## Blockchains and BFT - - -Any blockchain open to the world essentially has to solve the Byzantine Generals problem of reaching consensus among (un)trusted parties. The earliest blockchains addressed BFT by stating that higher computational power will increase the probability of proposing the next block (Proof of Work), i.e., using computational power as a substitute for identity. Over time, this led to an arms race of investing in computational resources, i.e., making higher capital investments to increase the likelihood of proposing a new block and thereby earning the associated rewards. Furthermore, this introduced the game-theoretic assumption that one would not harm the system they are highly invested in. Though this addresses Byzantine Generals' problem in a trustless setting, experience has shown that out-of-band coordination can lead to centralization (e.g. with the emergence of mining pools). Furthermore, PoW struggles to scale to the transactional demands of contemporary use-cases, creating along the way increased waste and exacerbating concerns about energy usage. - - -By decoupling the establishment of identity and reaching consensus, we could better solve the problems inherent in current approaches. Using alternative ways to establish identity, one could leverage BFT consensus protocols for scaling the blockchain system to meet the demands of high transactional throughput and faster finality times. - - -In most variants of BFT protocols a set of validators are committed to proposing and attesting new blocks. This set has to be stable and can only be altered at fixed intervals called epochs. Permissioned blockchains rely on Proof of Authority (PoA), wherein a centralized membership service provider authenticates and authorizes validators in the network. Eliminating the centralized membership service provider could lead to Sybil attacks as a malicious party can subvert the consensus protocol by creating many (pseudo)anonymous identities. - - -To achieve the benefits of BFT consensus, networks have two hard requirements: persistent identities and that the identities are not cheap. Said differently, the reasonable economic value which can be held on-chain safely will be as low as the cost of creating new node identities. - - -The only known Sybil resistance mechanism to achieve this in a permissionless setting is Proof of Stake (PoS). We have already seen the challenges of PoA and PoS systems in the previous section. - - -Puzzle towers may offer a new Sybil resistance technique worth exploring for permissionless environments, especially during network bootstrapping. In addition, puzzle towers might solve distribution and diversity challenges, at least to a certain extent. - - -## Puzzle Towers to bootstrap BFT networks - - -Puzzle towers were introduced by Dominic Williams in Sybil-resistant Network Identities From Dedicated Hardware. The key idea is to use chained work (such as a Bitcoin puzzle) to prove work done by an agent, wherein the cumulative count of proofs can also be used for providing certain guarantees. One such guarantee would be the cumulative time (or clock cycles) by an agent on the network. - - -Puzzle towers are sequential proofs of work. They consist of chains of proofs obtained from solving puzzles in sequence. The zeroth proof consists of a unique identifier of the owner, such as their public key, and all the proofs following it would have a hash of its previously verified proof. Each agentรขโ‚ฌโ„ขs puzzle tower height and last computed hash is stored on a chain, and this data can subsequently be used in consensus games while ranking the candidates in the validator set. - - -Puzzle towers act as a reputation by building persistent identity for the agent which is built with time and cannot be bought or transferred. - - -There's an additional benefit to creating a possibly wider distribution of initial consensus weights. In BFT, puzzle towers provide a way for consensus weight to get distributed to consensus agents (validators), without needing any permission, and without needing to purchase stake from a centralized actor. Even the genesis transaction of a network can include several puzzle towers from different actors, and a group of people can elect from those candidates a genesis validator set. - - -Puzzle towers signal a kind of reputation in the system; one that is acquired by actively participating in the network over time. The mechanism bears similarity to PoS systems where nodes that successfully engage in consensus have their rewards increase over time, and the ones that fail do not receive rewards. - - -Assuming native tokens earned as rewards for securing the network are not transferable between nodes, the consensus weight resulting from puzzle towers would be the same as in a PoS system. Said differently, at the start of networks a puzzle-tower-based vote distribution would correlate with the voting power in a purely PoS voting scheme. - - -The major differentiator is that no stake had to be acquired to participate. The players all start from the same position: A tower of zero height, and with zero coins. From then on, any node which computes delay towers is treated equally irrespective of stake they own, or when they joined. - - -Though we are not yet making claims about the steady-state Sybil-resistance of these implementations, puzzle towers may be a plausible genesis and bootstrapping ritual. - - -## Limitations of Puzzle Towers - - -The original puzzle towers design solves one distribution issue, namely that it doesn't require capital or permission to join a network. But unmodified, they do tend to benefit an existing community. Hash-based puzzles will suffer from the same race on hardware that plagues Bitcoin and will require highly technical people to set up and maintain nodes to receive \*any\* reward. This design sets a high barrier to entry for contributors. - - -Additionally, it is expensive, but not impossible, to forge a hash-based puzzle tower quickly. For instance, an agent with an ASIC miner could compute an impostor tower which someone started mining with a desktop computer. - - -Lastly, building a puzzle tower based on typical Proof-of-Work puzzles is expensive to verify. The puzzle towers -- if designed as sequential functions, as described -- are computationally expensive to verify their correctness because the verifier has to run all the steps again to obtain the result. When scaled-up this might consume most of the cycles a blockchain should use for its consensus and application layer. - - -Next we'll look at Verifiable Delay Functions as alternative work which can be done in a puzzle tower. - - - - ---- - - -## Full Series - - -1. [A high-throughput chain with a fair launch](http://openlibra.blog/2021/11/01/delay-towers-part-0/) -2. [Puzzle Towers for BFT](http://openlibra.blog/2021/11/05/delay-towers-part-1/) -3. [From Puzzle Towers and VDFs to Delay Towers](http://openlibra.blog/2021/11/08/delay-towers-part-2/) -4. [Implementation on BFT](http://openlibra.blog/2021/11/12/part-3-a-delay-towers-implementation-on-bft/) diff --git a/docs_old/archive/canonical/technical/delay_towers_pt_2.md b/docs_old/archive/canonical/technical/delay_towers_pt_2.md deleted file mode 100644 index 275bb200..00000000 --- a/docs_old/archive/canonical/technical/delay_towers_pt_2.md +++ /dev/null @@ -1,121 +0,0 @@ -## From Puzzle Towers and VDFs to Delay Towers - - -## TL;DR - - -By extending puzzle towers with VDF, a delay tower becomes a permissionless and non-forgeable identity which is fast to verify. This is a form of sybil resistance, we don't observe in any other system. A delay tower becomes a permissionless and non-forgeable identity which is fast to verify. These properties make a delay tower unique, scarce, and perhaps valuable in its own right. - - -## Context - - -Theย [first part](https://siasky.net/EABaWAXFy3Ztx1vVIpOfScjkRaTb1GrFeGRwqFKd6V-hAg)ย introduced puzzle towers for establishing a persistent identity in BFT blockchains. It concluded that using hash puzzles, practiced in PoW, would lead to an arms race in computing power leading to ASICs and mining pools. The goals are to avoid the arms race, to increase distribution, and additionally, the ideal puzzle should have the following properties: - - -1. Prevent creating significant advantage for high computing power -2. Instantaneous verification of the correctness of solved puzzle proofs -3. Work on a commodity machine without additional hardware - - -To address these issues, in Part 2 we investigate verifiable delay functions as a means of enhancing puzzle towers. - - -## VDF 101 - - -[Verifiable Delay Function](https://eprint.iacr.org/2018/601.pdf)(VDF) is one of the latest discoveries in cryptography, popularized by Dan Boneh, Joseph Bonneau, Benedikt Bunz, and Ben Fisch. It is a cryptographic primitive for providing a guarantee that a lower bound of time has elapsed. - - -VDFs are used to prove a delay in a verifiable manner. In other words, VDF slows things down by taking a specified number of steps to compute. VDFs satisfy two properties: - - -* **Sequentiality:**ย One cannot parallelize their computation. -* **Uniqueness:**ย Given an input, the output is unique and deterministic even though the proofs might vary. - - -VDFs are composed of three functions: - - -1. *setup()*ย - takes in system configurations and credentials to initialize. -2. *evaluate()*ย - the delay function which takesย *t*ย sequential steps to compute. -3. *verify()*ย - a Boolean function to verify the correctness of the output and proof. - - -Theย *evaluate()*ย function is the delay function which takesย *t*ย sequential steps to compute and generates an output and a proof. In 2019, aย [paper](https://eprint.iacr.org/2018/601.pdf)ย proposed a generalization of time-lock puzzles as a candidate for theย *evaluate()*ย function. The function is given as follows:ย *f(x) \= \[x^(2^t)]* - - -The final step in the VDF construction is theย *verify()*ย function, responsible for verifying the correctness of output and proofs. The candidates forย *verify()*ย were independently presented byย [Wesolowski](https://eprint.iacr.org/2018/623.pdf)ย andย [Pietrzak](https://eprint.iacr.org/2018/627.pdf)ย in 2020\. Theย [implementation study](https://eprint.iacr.org/2020/332)ย states that the Pietrzak scheme is more efficient than Wesolowski as it takes less time to verify the correctness of the output and proofs. - - -This section isn't an in-depth guide to VDF; instead, it evaluates VDF for its use with puzzle towers by creating a cumulative proof of elapsed time. To conclude, VDFs can take an arbitrary amount of time to be computed, serving as proof of elapsed time, and one can verify the proofs almost instantaneously. - - -## Extending the Puzzle Towers with VDFs - - -Puzzle towers prove the sequential work done. However, using PoW style puzzles gives undue advantage to better computational power. The design goal is to solve puzzles that prove work done or time elapsed. Several protocols have a variation on this, includingย [Solanaโ€™s Proof of History](https://solana.com/solana-whitepaper.pdf)ย (PoH).ย Solanaโ€™s white paper states that this approach needs all the steps in the sequence to be replayed for verifying correctness, which could be an expensive operation. VDFs help us establish an alternative to hash-based PoW that is both sequential and easy to verify. Currently, Chia uses VDFs in its core protocol, Proof of Time (PoT), to ensure consistency in block times. - - -Simply put, delay towers are created by replacing the puzzle in the puzzle tower with VDFs. The delay towers are a sequential series of sequential work. Every miner in the network initializes their delay tower by running aย *setup()*ย function with their mnemonics and configurations. After setting up, the miner runs theย *evaluate()*ย function locally, and this is the delay component to produce output and a proof. Every miner sends proof as a transaction to the network. The validators verify the correctness of proofs submitted by miners usingย *verify()*ย function. If valid, the validators update the miner state, i.e., increase the height of the delay tower for that miner and the hash of last verified proof on the blockchain. The miners need to use the hash of the previously verified proof as an input for evaluating the following proof, building a delay tower for that miner. As more and more proofs are submitted, the height of the delay tower for the miner rises. The height of the delay tower signals how long a miner has been mining proofs in the network, thus used for ranking the candidates for the validator set. - - -From the original design of puzzle towers, delay towers improves on: - - -* **Wasted cycles:**ย Eliminating randomness leads to determinism in increasing the tower height. VDFs cannot be parallelized, and they do not benefit significantly from alternative hardware such as GPUs. With reduced computational requirements, there are minimal compute cycles and hence, lesser carbon emissions. -* **Distribution:**ย Determinism leads to predictability for users not using specialized hardware, making it more inclusive. -* **Faster verification time:**ย Given a proof, VDFs are quick to verify. The validators verify the correctness on-chain as part of the protocol with minimal resources. - - -This allows for a new Sybil resistance mechanism while overcoming the limitations of PoS based networks while bootstrapping a new permissionless blockchain ecosystem, with a fair shot at an equitable outcome for the participants over the course of history. - - -## Integration - - -The delay tower in itself does not provide all the guarantees in isolation. The tower needs to be confirmed against a main blockchain regularly. With that in mind, many additional constraints can be added in smart contract logic, and even updated dynamically. - - -One could set many parameters, perhaps even dynamically, such as the lower bound of time to compute a proof. The VDFย *evaluate()*ย is configured to take 30 minutes to compute, and thenย *verify()*ย takes around 260 milliseconds to validate correctness. - - -* **Time:**ย Lower bound of of time to evaluate the VDF - + Increasing the threshold of time to an hour means that massive CPU harvesting attacks through zombie networks become infeasible since host systems are needed to be used for extended periods without the ability to parallelize the work. -* **Threshold of quantity:**ย Too many or too few proofs. - + To prevent very few proofs being created a minimum threshold per period can be included. - + Likewise an arms race scenario can be disincentivized by having an upper bound on proofs submitted in a period for a given benefit (e.g. this could gate subsidies, or even prevent entry into the validator set if it goes beyond the ceiling). -* **External information into the preimage:** - + Similar to Chia Timelords, a block header can be included in each VDF such that the user needs to wait for a block header before submitting a proof. The sequential nature of puzzle towers means that any excess proof done while waiting for the block header will not be valid. - - -## Conclusion - - -There are some differences between a VDF (delay tower) and a proof-of-work puzzle (puzzle tower): - - -* Determinism - no randomness -* Lower bound on time -* No wasted cycles -* Sequential - cannot be parallelized - - -Delay towers based on VDF make it impossible to forge a tower in meaningfully less time than it took the original user, even for anyone with infinite capital and computational resources.ย **This is a form of sybil resistance, we don't observe in any other system. A delay tower becomes a permissionless and non-forgeable identity which is fast to verify. These properties make a tower unique, scarce, and perhaps valuable in its own right.** - - -The following and final part of the article will discuss one implementation of delay towers. - - - - ---- - - -## Full Series - - -1. [A high-throughput chain with a fair launch](http://openlibra.blog/2021/11/01/delay-towers-part-0/) -2. [Puzzle Towers for BFT](http://openlibra.blog/2021/11/05/delay-towers-part-1/) -3. [From Puzzle Towers and VDFs to Delay Towers](http://openlibra.blog/2021/11/08/delay-towers-part-2/) -4. [Implementation on BFT](http://openlibra.blog/2021/11/12/part-3-a-delay-towers-implementation-on-bft/) diff --git a/docs_old/archive/canonical/technical/delay_towers_pt_3_implementation_on_bft.md b/docs_old/archive/canonical/technical/delay_towers_pt_3_implementation_on_bft.md deleted file mode 100644 index 52bcb6d7..00000000 --- a/docs_old/archive/canonical/technical/delay_towers_pt_3_implementation_on_bft.md +++ /dev/null @@ -1,199 +0,0 @@ -## TL;DR - - -Delay towers provide many benefits to BFT networks, including diverse distribution of participants, Sybil resistance, eco-friendliness, determinism, and others. This post delves into one specific implementation of delay towers and its integration with a high-throughput BFT network for bootstrapping purposes, and offers it as a strategy to achieve the goals of a free and fair chain launch. - - -## Context - - -If you followed the previous parts, you'll recall that we are using delay towers to bootstrap a new blockchain with the following properties: - - -* High-throughput -* Fast finality time -* Fair launch -* Permissionless access -* Engender decentralization with equitable distribution - - -A blockchain protocol can use delay towers to establish persistent identity for the nodes as a Sybil resistance mechanism. Delay towers serve as a proof of elapsed time (PoET) to complement BFT consensus, providing a mix of security and performance benefits that PoS ordinarily provides while preserving regulatory benefits of PoW and lowering barriers to distribution. This post delves into one specific implementation of delay towers to envision how all the pieces of delay tower and BFT fit in. - - -## Delay Towers Implementation - - -### VDF Implementation - - -The growing demand for VDFs for applications, such as randomness beacons, has led to various implementations of VDFs. The current protocol uses Chia's VDF implementation. Chia sponsored some of the early work around VDFs and has an actively deployed open-source implementation with benchmarking. Another notable implementation is Stark VDFs that use computational integrity proofs such as Starks, pioneered by Starkware with VeeDoo service on Ethereum. Other VDFs include RSA moduli and trusted setups which are yet to be deployed in the wild. - - -### Anatomy of a Delay Tower - - -Nodes run the delay function locally, offline, using the "tower-builder" application to produce aย *proof\_0*ย file. The proof file consists of: - - -* A Preimage with account authorization key (public key), the chain ID with an arbitrary state of the ledger -* The hex encoded bytes of the proof of the delay. -* The metadata, such as the delay time. - - -The preimage serves as the base identity for which the remainder of the delay tower will be referencing. Ultimately the preimage is committed to a chain, and the state machine will verify that the preimage belongs to an account on the chain. - - -All the subsequent proofs will use the preceding proof's SHA256 hash as an input for evaluating their delay functions; the "tower-builder" application builds new proofs on top of existing proof to grow the delay tower. Each new block is then submitted to the chain ("committed"), and thus verified as (A) being a valid proof of elapsed time and (B) being contiguous with the previous proof committed to the chain - thus giving a linear path back to the original preimage. The proofs do not need to be stored on chain after they have passed those two approvals. Only the current proof's hash needs to be persisted on the chain, in anticipation of the next proof which will be verified. - - -As for the state of the tower, the delay tower is stored locally on the node as a repository of JSON proof files. Each proof takes approximately 4kB. The tower state lives off-chain, which the user stores on their node and is responsible for backing up. This would allow for the user to replay the entire tower history if there was a need to do so (e.g. using as identity proof on another chain, or in the event of the principal chain's catastrophic failure). - - -That said, additional governance is necessary to prevent outliers from exploiting validator set admission and consensus voting power (as discussed further below). As we've seen, above, the state machine encodes certain rules for the submission of the tower. Upper and lower-bound threshold of proof counts can be employed. - - -For upper bounds, for all accounts on chain (whether a validator or not) the state-machine will outright reject proofs after an excess amount of proofs have been submitted in a given epoch (one day in our case). This is an important check to remove outliers which can happen due to either: Exploits in the cryptography (which as yet undiscovered) or advances in hardware that would allow for order-of magnitude improvement. The upper-bound disincentivizes such investments. - - -Similarly, additional rules exist for a lower-bound. The chain may disconsider "sufficient" proofs as having been submitted for certain cases. For example a minimum number of proofs per epoch would be necessary to join a validator set for the first time, be removed from "jail" for non-compliance, or simply in order to remain in the validator set, etc. This is discussed further, below. While in the experimental network these thresholds are hard-coded and can be changed by protocol upgrades, future implementations can make such VDF thresholds dynamic, varying according to current system state. - - -The description above sketches out the lifecycle of an individual delay tower. Let us examine how it integrates with a BFT blockchain chain. - - -## Network Genesis - - -At the genesis of a network, the BFT chain needs a defined set of validators in the system state. Different genesis "ceremonies" are possible in creating BFT networks. In Proof of Authority, a centralized entity simply provides a genesis "layout" with the nodes that are to participate. - - -Coordinating a network genesis such that it is permissionless requires some infrastructure in order for nodes to make themselves candidates for genesis (registration). Usually a Github repo is used for this purpose. Once all the registrations are present, individual node operators will use a layout file with the registrations that they would like to see included in the first block of the network. In the case of using a delay tower, their proof\_0 can be included in the registration information. - - -During the registration period, the validators candidates will generate offline and submit proof\_0 along with their node configurations (such as network and public keys) to the ceremony repository. After the registration period closes, each node participating in genesis will use a genesis building tool to produce the first block of the network. Note that the genesis block does not need to be produced by one entity, each node in the new network can create the genesis.blob independently for a fully decentralized ceremony. One of the steps of the tool in our case, is to run a VDF "verifier" that confirms that proofs of each registrant indeed correspond to an expected delay and that the preimage of proof\_0 belongs in fact to the registrant. At the end of the process the genesis block for the network is produced. In this proposed implementation, a successful bootstrapping requires neither pre-mining, a coin drop, nor any other means of distributing the necessary starting stake(s). - - -## Steady State - - -### Onboarding Nodes - - -As in the genesis ceremony, each new prospective validator node (a node that wishes to enter a validator set) needs to submit configuration information to the network. After genesis, the only way of doing this (in any account-based blockchain) is to have an existing account create the new prospective account and optionally, send the configuration information on behalf of the prospective validator. For this to take place, the prospective validator must generateย *proof\_0*ย locally and transmit it (out of band) to an existing account to initialize its configurations. As discussed below, further governance can be added to the account creation, such as requiring these accounts to be created by existing compliant validators, and rate-limiting the account creation by the onboarder account. - - -In a single step, one transaction, the onboarder can submit the validator's configuration information and theย *proof\_0*ย (whose delay can be verified on chain via the transaction). Assuming all configuration information is valid (such as network settings) and theย *proof\_0*ย is verified the prospective validator can become a candidate to enter the validator set. - - -### Mining - - -The governance can decide at what point the validator can join the validator set. In this proposal, the validator candidate needs to continue to produce proofs for a full day (one epoch) before they are admitted to the validator set. - - -To grow their delay tower, nodes run a "tower-builder" app. Running the "tower-builder" application is called mining. The tower-builder operates in parallel to other node operations, e.g. the consensus node executable runs in a completely separate process. The tower-builder could in fact be run in a separate environment as the consensus process. - - -From this point on, the miner is building the delay tower. The miner submits the VDF proofs and the chain state machine verifies the correctness of submitted VDF proofs. However, for the node operator the quantity of proofs must be created within certain thresholds. These thresholds may adapt over time. But on bootstrapping the network, a generous threshold will make allowance for operator's adapting to this system. In this implementation, a minimum of 7 proofs need to be produced per epoch (approx 4 hours of proofs per day as measured on typical cloud hardware), but an upper bound of 72 proofs per epoch (e.g. 20mins per proof continuously running). This range will narrow as more system information is collected from real-world usage. Furthermore these thresholds can be dynamically adjusted, but further research is needed. - - -As noted in the previous post, mining delay towers is not the same as PoW puzzles; it is sequential, cannot be parallelized, and has no advantage with heavy computational power. As a result, mining delay towers are indeed very eco-friendly. - - -### Consensus Voting Power - - -The BFT protocol needs a supermajority to reach consensus on block production, and every validator has some "votes" in the consensus, called voting power. In this implementation, the tower height equals the voting power in the consensus. This is a deterministic and straightforward rule that is easy to verify. - - -Over time, the relative linear advantage of an early node decreases, and the marginal difference between a tower starting later, will decrease and voting power becomes more evenly distributed. This could be a benefit over PoS networks where reputation and rewards are directly dependent on the stake. - - -While a longer discussion is necessary on economics, it should be noted that tower height need not confer any economic advantages besides admission to the validator set. In this design, all the validators in BFT contribute relatively equally, and any major differences are often due to operator error. Hence, there's no need for consensus power to affect rewards for participating in the validator set (as is often the case for PoS).The rewards are shared equally among all the compliant validators. - - -### Cardinality - - -BFT network performance worsens if the cardinality of the validator set is too high; accordingly an upper limit on the validator set is needed. There are upper bounds to BFT network performance; there is a steep dropoff in network latency observed after 128 network nodes in most BFT consensus implementations. Thus the participation in the quorum set needs to be restricted. - - -Different BFT networks use different strategies to select the validator set, these are typically Proof of Stake (as pioneered by Cosmos). Variations incorporating some measure of randomness exist. The simple algorithm is picking the top N validators by Proof of Stake from the list of validator candidates. - - -Delay towers could provide an alternative. The consensus power, as defined by the delay tower height, can determine the validator set in a direct, observable, and deterministic manner Similar to the rule described above. The Top N validators by tower height gain admission to the validator set. - - -Again while this is a separate discussion on economics, the design above is not entirely sufficient for game theoretical equilibrium since it would penalize new entrants who may be doing more delay proofs, instead of incumbents who may abandon running the tower-builder. - - -As mentioned above thresholds can be enforced by the chain. A miner that intends to be part of the validator set needs to mine at least K proofs to state to gain admission in the following epoch. This is true for new prospective validators, as well as the existing validators. - - -### Jailing - - -Based on whether the validators are validating blocks (proposing and signing blocks) and/or mining, the validators could fall in one of these categories. - - - - -| Case | Validating blocks | Mining delay tower | Gets reward | Jailed | -| --- | --- | --- | --- | --- | -| 1 | Yes | Yes | Yes | No | -| 2 | Yes | No | No | No | -| 3 | No | Yes | No | Yes | -| 4 | No | No | No | Yes | - - -The validators who are not validating blocks are not contributing to the consensus. This will increase latency. For instance, if a failed validator is chosen to propose the next block, the network has a timeout in that round instead of a new block. Even worse, if more than one-third of voting power is not reached, finality is affected. Therefore, this behavior must be disincentivized, and the validators who do not meet a threshold within an epoch are jailed. Note that the nodes that are not mining are not punished because they are not affecting the network. - - -### Rate Limiting Validator Entry - - -The validatorโ€™s entry into the network is an attack surface, including possible Sybil attacks. One potential approach, without PoS and an active centralized membership service provider, is to ask all existing validators to vote on the new validator. However, this approach could lead to encouraging validator-wide agreement (politics) for expanding the validator set. As an alternative, every validator could be rate-limited, and only those who are actively contributing (i.e., mining, and voting for 14 epochs) obtain an invite. This invite can be used to onboard a potential validator by initializing their validator configurations and these invites cannot be transferred or accumulated. At any point, there can be no more than one referral for a validator. - - -Assuming no more than one-third of validators are malicious, as the network grows from a seed root of trust (as all blockchains do), the damage a Sybil can conduct to consensus is limited; the sybil cannot amplify their consensus votes faster than the good actors amplify theirs. Rate limiting also prevents one actor (e.g., a "foundation") from assigning seats in the consensus since they are rate-limited as other actors. - - -## Benefits - - -The implementations above are an experiment; a proposal on how to integrate Delay Towers into networks which typically are PoS or PoA Sybil resistant. - - -To recap: bootstrapping a BFT network with delay towers has multi-fold benefits: - - -* Delay towers provide an equal playing field by making it hard to repurpose existing hardware, e.g., PoW ASICs. -* Bootstrapping a network without external capital or ICOs. -* Delay towers offer better distribution by lowering the barriers to entry. Can run on any commodity hardware. -* Similar security as PoS network during bootstrapping. With withdrawal limits in place, delay tower height correlates to the stake in native tokens in PoS systems. -* Delay towers provide a persistent identity that is hard to forge. -* Eco-friendly consensus with minimal energy usage. - + Determinism and hence, no wasted cycles - + Delay towers are sequential and are not parallelizable by nature. - + Upper limits on number of accepted proofs per epoch caps the arms race. -* Economics that are familiar to users of PoS networks. The rewards are distributed similarly to PoS networks, wherein everyone contributing to BFT consensus is rewarded. - - -## Conclusion - - -Delay towers envision a permissionless, durable, and non-forgeable identity which is fast to verify. This post delves into specifics of productionizing delay towers by integrating them into a BFT network. Delay towers serve as a persistent identity that can be used for consensus power while bootstrapping the network. - - - - ---- - - -## Full Series - - -1. [A high-throughput chain with a fair launch](http://openlibra.blog/2021/11/01/delay-towers-part-0/) -2. [Puzzle Towers for BFT](http://openlibra.blog/2021/11/05/delay-towers-part-1/) -3. [From Puzzle Towers and VDFs to Delay Towers](http://openlibra.blog/2021/11/08/delay-towers-part-2/) -4. [Implementation on BFT](http://openlibra.blog/2021/11/12/part-3-a-delay-towers-implementation-on-bft/) diff --git a/docs_old/archive/canonical/technical/proof_of_fee_part_1.md b/docs_old/archive/canonical/technical/proof_of_fee_part_1.md deleted file mode 100644 index cabdf21f..00000000 --- a/docs_old/archive/canonical/technical/proof_of_fee_part_1.md +++ /dev/null @@ -1,397 +0,0 @@ - -## The Cost of Consensus - - - - -ย  - - - - -ย  - - - - -### TL;DR - - - - -As an alternative to the (near-universally deployed) Delegated Proof of Stake (DPoS), we propose Proof of Fee (PoF), a sybil resistance technique designed natively and with consideration of the benefits and tradeoffs of PBFT consensus from empirical experience. - - - - -* Profits to blockchains are slim to non-existent. Low consensus costs are foundational for any chain that wishes to provide consumer surplus and profit to coin-holders; where excess winnings of the chain can be distributed to *all* account holders without preference to an investor class of "stakers". -* In PoF the cost of consensus is lowered maximally to the *operator opportunity cost*; with such an approach, the social cost of dilution through issuance is minimized. -* Validator seats are auctioned at each epoch, such that the validators private valuation of rewards, MEV, breakage, and governance is revealed. -* PoF coins have superior ergonomics. Every actor has a very simple instruction; no staking, no delegation, no yield games, no slashing. - - - - - -``` -Before we dive into the mechanics of Proof-of-Fee, in Part 1 of this paper we lay some foundations which may be different from what you have seen elsewhere. [Part 2 of the paper](http://openlibra.blog/2022/10/20/proof-of-fee-part-2-a-proposal/) gets into the mechanics and implementation details of Proof-of-Fee (PoF), an affordable sybil resistance technique native to PBFT consensus. -``` - - - -## Why Not Delegated Proof of Stake? - - - - -While the purpose of the document is not to dissect DPoS, what followsย  is the briefest contextย  on reasons why DPoS may not work for a blockchain's community.ย  - - - - -A meaningful issue is the "ergonomics" of the token, that is, how do humans interact with it. End users may be unsophisticated and not know how to stake. They may have coins on an exchange which does not offer staking services. The coins may be in escrow in an application's smart contract, or across a bridge. Some of these issues are surmountable if there were sufficient education and infrastructure, but in the meantime the result is a disparity between the percentage of tokens staked and the percentage of account holders. A large percentage of the token supply may be staked (by whales and the savvy coin holders), but it represents only a small number of the total wallets. - - - - -Modern DPoS blockchains are also universally deployed with "inflation" or issuance of new coins to subsidize the validator operators and their stakers. This may be necessary because transaction fees from producing blocks are far lower than the validators deem acceptable to provide their services. - - - - -The result is that the accounts which are not staking are effectively paying a fee to the stakers. This means usually the retail investors are paying a fee to keep an account on the chain (a wealth tax) often to the founding members of the chain (venture capitalists and developers). This is not a widely advertised property of such chains.ย  - - - - -Promoters of the chains may say that this is transitory, that transaction fees will one day catch up, but this should be viewed with some skepticism. Looking forward to the next ten years, the cost of each state transition on a blockchain will drop radically due to secular engineering advances (e.g., parallelization, mempool optimization, sharding, layer 2, etc.); given a trend towards commoditization, prices tend to drop to marginal levels. Given the likelihood of a paucity of revenue from transaction fees, DPoS blockchains may be structurally and permanently in the business of taxing the depositors. - - - - -There is also some debate around the "delegation" component of DPOS and whether it is serving its purpose. Delegation is expensive as it adds to the cost of consensus (because now there are more people, and more opportunity costs, that need to be compensated). The cost must achieve the goals of plausible neutrality (decentralization) and select for ideal validators. Instead, the empirical evidence of what delegation does is select for the parties that can accumulate capital (e.g. large centralized exchanges). That behavior does not necessarily align with achieving the goals. - - - - -Lastly, the staking requirements may be excessive, inefficient uses of capital. One should ask the question: Does the bond really need to be 1,000 to 1,000,000 times the reward of an epoch? Given that L1s have not empirically seen slashing of large stakes from malicious attacks, the level of bonding is disproportionate to the need (more below on nothing-at-stake issues). - - - - -We start from the assumption that more exploration needs to be done on economic guarantees for modern blockchains, which are mostly all based on PBFT and derivations thereof. Proof of Fee is proposed as an experiment. - - - - -## Validator Economics - - - - -Since validators are the largest cost of a network, we need to clearly understand their costs and their expected utility from participating in a network.ย  - - - - -Validators have a private valuation (*expected utility*) of a seat in consensus. The same validator has a private opportunity cost for the work it provides. If the expected utility is greater than the total costs, including opportunity cost, then a rational validator should participate in consensus. - - - - -### Validator Costs - - - - -One of the roles of protocol engineers is to lower the hard costs associated with being a validator; make the tools work reliably, make the node software use less hardware resources, and provide greater automation and monitoring. - - - - -Technical matters, however, cannot address all of the costs of the validator; there are also opportunity costs. The time it takes for the staff to operate the nodes, research, participate in governance, and do business administration could be used for other purposes (on other chains). Additionally, if there is a financial cost such as staking, then that value could always be used elsewhere, staked elsewhere. - - - - -Opportunity cost is out of the control of protocol engineers and designers, it is a feature of the global markets (labor, tokens, compute, energy, etc.). - - - - -### Validator Utility - - - - -Given that the opportunity cost is extrinsic, profitability for the validator (and the blockchain) is created by the business environment of the blockchain. Some of the factors that contribute to the private assessment of the utility of the validator seat are tangible and easily measurable (transaction fees), others are intangible and highly subjective (governance roles). - - - - -#### *Transaction Fees* - - - - -Most blockchains describe transaction fees as a title (property right) of node operators. (Note in Proof of Fee we take the view that transaction fees are a title of the coin holders, more on that later). The transaction fees flow by default to network operators. Most often those fees are far lower than what those same validators are earning from network subsidies. - - - - -#### *Subsidies* - - - - -Most blockchains provide subsidies in addition to transaction fees. This is supposed to supplement the validator's earnings while bootstrapping the network and the transactions are insufficient. Even in 2022 the most established blockchain, Bitcoin, generated only a fraction of earnings from transaction fees: Roughly 1% (i.e., roughly 99% comes from subsidies - see the chart, below). - - - - -![](https://lh4.googleusercontent.com/IDSFhHIiMq_FQMvE7JKvK9tlUD9pKIRvXl-XJ_aDk5U2bur44IjQAQLx41gfWYUn6xOKHTKMkrR1Y2x--7UguUH0L-WlUJhpiW92PRzTEda8Ix8_uo_4HWSU3vsP1zMUl-IsbKcAR4LpyuihYRg6mN5pkX-gkBzwWr3OiJmDqXBcAlm5kYsc5kTu) - - - - -Source: [TheBlock.co](https://www.theblock.co/) - - - - -As a matter of practice, subsidies are almost exclusively newly issued network equity, and as such are dilutive. Meaning, subsidies are a cost to depositors on a blockchain due to the reduction in their percent equity. Assuming a network with a constant market-cap valuation (which we must do from a unit-economics analysis), new issuance to the miner which produced security, is a reduction in value to anyone who didn't receive a new coin. Additionally, this new equity is financing the current security needs by time shifting future earnings from transaction fees (presumably, unless new revenue models are discovered). - - - - -All known blockchains are loss-making in this regard. While Ethereum makes some claims about becoming profitable, it remains to be seen whether this can be sustained over more than a brief period (, and there are at least a few pundits out there who are questioning that claim).ย  - - - - -#### *No-Show Rewards* - - - - -Another aspect of validator utility to consider is no-shows from other validators, that is, drop-outs from competitors. When a validator is successful in the validator set, and one or more of its peers fails in consensus, there is a surplus of transaction fees (or subsidies) that are available to it. Meaning, the pool of rewards within an epoch is greater than what was nominally attributable to the validator at the start of the epoch. We separate this from the topic above because chance is involved and part of the utility is a wager on the success of the peers. - - - - -This is relevant because even if validation is nominally not profitable from transaction fees or expected subsidies, the validator may see value in "staying in the game" in case another node falls out. - - - - -#### *MEV* - - - - -MEV is a category of earnings that a validator can create by engaging in different types of frontrunning as it prepares transactions into blocks. As of 2022, this has become an important source of revenue for many operators.ย  - - - - -Though MEV seems to be becoming acceptable in some circles, when viewed through another lens, it can be argued that engaging in MEV violates the spirit of the agreement between validators and users. Validators are employing their access to insider information to game the system. From that perspective, MEV is an attack on the integrity of the system. (You can view a compilation of MEV attacks documented at [https://www.mev.wiki/attack-examples](https://www.mev.wiki/attack-examples).) - - - - -From 2021 to 2022, the tools for engaging in MEV attacks have become commoditized on Ethereum, and the cumulative costs approach $700M taken from users. - - - - -![](https://lh6.googleusercontent.com/J6P-cUzicXGsCa6TyeCe8YmYykkYsOKnZpB5EQ1G6IvbG-rWc-b1JE98Blvhfz1yHsdA02I19Y34R8xSib4v1JKFNcqnPI42hgi5tqXFLY-9n2fFe7N6ZafPT4f-6-DUUByYx4D3tGR0UYn_SYhoX61inTYU8zl02joNeunR5oDsBq5N-3oZIKPJ) - - - - -Source: https://explore.flashbots.net/ - - - - -MEV can be significant. In the early days of the Ethereum Post-Merge, as the cost of consensus went down, the share of MEV became higher. In September 2022, post merge, the MEV would average $100K, per day, while earnings from subsidies was $2M and transaction fees roughly $700k. Though on certain days, there are worrisome outliers, on September 27th 2022, the total subsidies paid to operators was $2\.14M, while Tx Fees was $0\.67M and the MEV was $1\.5 M, that is 50% extra earnings over expected in-protocol earnings. (see, [https://www.theblock.co/data/on-chain-metrics/ethereum](https://www.theblock.co/data/on-chain-metrics/ethereum)).ย  - - - - -In the long term there may be technical solutions to MEV attacks, such as the block producer and proposer separation seen in Ethereum (Flashbots MEV-Boost Relay). There may also be solutions on the application layer for "tricking the bots" (see: [https://www.mev.wiki/attempts-to-trick-the-bots](https://www.mev.wiki/attempts-to-trick-the-bots)), and for fun see some applications' mousetraps: ([https://www.coindesk.com/tech/2021/03/22/bad-sandwich-defi-trader-poisons-front-running-miners-for-250k-profit/](https://www.coindesk.com/tech/2021/03/22/bad-sandwich-defi-trader-poisons-front-running-miners-for-250k-profit/)) - - - - -#### *Governance* - - - - -Validator utility also includes the exercise of governance rights. Validators have outsized roles in governance (parameter changes, state machine upgrades). In fact, it may be said that validators hold the only "hard power" governance. Validators can always coordinate to apply a write to the database and that control over the protocol gives them de facto power to set policy. Most chains try to apply lower friction ways of other stakeholders changing policy, however ultimately the validator has the last say (or veto) on policies. Even if there are other governance mechanisms on-chain, validators may in collusion reject such transactions which trigger an upgrade (more below on types of malicious behavior). Resolving this balance of power is not the topic of this paper; suffice to say that the validator can reasonably have a private valuation for this governance role. - - - - -## Cost of Consensus - - - - -Consensus is a shorthand for getting a database transaction approved, though there is some confusion in equating a consensus algorithm, and a sybil resistance mechanism. Usually when we refer to cost of consensus we mean both inputs. Proof of stake was an evolution in reducing the cost of preventing sybil attacks, in both reducing the hardware costs in preventing attacks from malicious actors. - - - - -### PoW Sybil resistance - - - - -Nakomoto consensus (invented for Bitcoin) relies on the longest chain principle, but it depends on Proof of Work (PoW) for sybil resistance. The longest chain principle helps in sequencing blocks of transactions, but not just anyone is allowed to do that. PoW as an identity mechanism says the block is proposed by the largest pool of CPU power. The more the CPU power of a pool, the more likely they get to propose the next block and hence, better rewards. As long as most CPU power rests with honest nodes, they outpace Byzantine actors by proposing more blocks.ย  - - - - -Over time, the demands for computing power kept rising from CPUs to GPUs to ASICs. As a result, the capital for infrastructure and the recurring cost of electricity resources kept growing, leading to increased costs for consensus (besides energy we have cost of capital).ย  - - - - -### What PoS solves and the Nothing-at-stake problem - - - - -Proof of Stake (PoS) addresses Sybil attacks using native tokens as a stake in the system in place of the capital requirements of the hardware. This approach significantly lowers the cost of sybil attack behavior compared to Nakomoto consensus plus PoW due to a drop in the cost of computation (since no proof of work puzzles need to be solved).ย  - - - - -However, this reduced cost could lead to nothing at stake problem wherein validators could behave arbitrarily (see, [Vitalik's original](https://blog.ethereum.org/2014/07/05/stake) description of the nothing at stake problem). In short: It's cheap for validators to create forks of the network, for example in a long range attack creating many plausible forks that in the future may be presented at the canonical fork. And for this reason, the earliest DPoS chains implemented high deposits and "slashing" when double-signing was occurring. As we will see later, there has been debate as to whether the threat of the penalty has any effect, or if the value of the bond is actually the cost-of-capital of the parked coins, thus negating that there is really a nothing-at-stake issue. - - - - -DPoS can be applied to numerous consensus algorithms (including Nakamoto, though not plausibly). The most well known is Tendermint PBFT implementations (or derivatives of Cosmos Hub), but there are many others in the wild. - - - - -Our concern is narrower: How economic guarantees interacts specifically with PBFT and its derivatives. - - - - -### Profitability - - - - -If a network is profitable it will return value to coin holders. For this to happen, the revenue of the blockchain's products must be greater than the costs. That is, there can be no issuance of coins to fill the gap between what end-users paid for services, and the different costs of goods sold (the validators). As of 2022, there has never been a reliably profitable blockchain. - - - - -Currently the infrastructure costs of most blockchains are equal to the cost of consensus (i.e, only nodes and miners are paid).ย  The true cost of consensus, as noted above, is not really technical or resource bound on post PoW chains; itโ€™s the sum of the opportunity cost of validators. Validators have other means of using their time and compute resources to make money. Assuming a security guarantee of *S*, the validators have a cumulative opportunity cost of *C* (we don't assume these to be equal, or even necessarily correlated). - - - - -During bootstrapping of a network the relation between opportunity cost and issuance is indeterminate, since the network is discovering its value. In **steady state** however, the costs to the network should be the lowest possible (approaching the opportunity cost of node operators), such that the costs can be more readily covered with revenue. If the revenue cannot cover the cost of security, historically, chains have covered the shortfall by charging fees to account holders; those fees come in the form of dilution through issuance. Put another way, they pass through the costs to the account holders. - - - - -Chains can only provide security if the opportunity cost of a sufficiently non-colluding validator set is being met. Chains can only cover those costs if they are solvent (they have revenue). The chains can finance the deficit with issuance, but this is also a tangle since it can only have value if it is long-term solvent (by eventually having revenues greater or equal to security costs). Another way to think about it: Issuance is financing; it is only shifting the future revenues to the present validators. - - - - -### PBFT Further Lowers the Cost of Consensus - - - - -Proof of Stake is the dominant method of sybil resistance for PBFT chains. Proof of stake designs, however, predate implementation of PBFT consensus. The specifics of PBFT chains allow for different economic guarantees but, for historical reasons, those have not been fully explored. Moreover, there are some misunderstandings about the total security guarantee of PBFT chains in relation to economic costs. - - - - -### Background on PBFT - - - - -The Byzantine Generals problem was posed four decades ago in 1982\. The problem it addressed was how to reach a consensus among participants who might not necessarily trust each other and could have Byzantine failures. Reaching consensus facilitates state machine replication among distributed systems, where Byzantine failure is any arbitrary behavior, including intentional and unintentional behavior such as crash failures, collusion among participants, and software bugs. A solution to this problem is Byzantine fault-tolerant (BFT) consensus algorithms, a family of consensus protocols for distributed systems that provide both safety (โ€œbad things donโ€™t happenโ€) and liveness (โ€œgood things do happenโ€) guarantees.ย  - - - - -The early BFT protocols assumed synchrony (i.e., synchronized clocks); that expectation can be challenging to obtain practically on the internet. PBFT is the first prominent practical solution to the Byzantine Generals problem. PBFT found its application in safety-critical systems, such as aircraft and submarines, where hardware is complex and may become unreliable in unpredictable ways, sometimes in hostile environments. Over the past two decades, we observed numerous advances to PBFT protocols with advances in networking and cryptography. These advances have significantly improved performance, measured throughput (tx/sec), and latencies.ย  - - - - -Blockchains, where trust and security are critical, can leverage the underlying correctness guarantees of PBFT protocols. One downside, however, is that PBFT protocols assume a committee of participants and therefore can face Sybil attacks where a single participant has created multiple identities. To address this challenge, mechanism designs for establishing identity and economic incentives with guarantees from game theory are often necessary. One such mechanism widely used in blockchains is Proof of Stake, wherein anyone with native tokens in the system stakes their assets to become participants in the network. We've pointed out some of the issues with this sybil resistance approach, above. - - - - -History won't end with PBFT, there may be other consensus innovations in the future. For our purposes we assume that the technical cost of consensus (CPU, networking, disk) is a domain of computer science and that the lowest hanging fruit has already been plucked, absent a major breakthrough in the Byzantine Generals Problem.ย  - - - - -### Walking the graph: The Disconnect Between Security and Cost - - - - -Let us consider the common threat scenarios, relative to PBFT: - - - - -1. Malicious transactions : Impossible unless signed by the user. One cannot append malicious transactions even if they have a majority. State machine replication would not let this happen and is guaranteed by cryptography. -2. Reverse/delete blocks after finality: Leads to another fork, means abandoning the current chain. For that fork to continue it requires aย  2/3rd majority on each block of the new fork. -3. Malicious writes: Requires 2/3rd of nodes to approve a forced malicious write. This also requires coordinated action among the malicious validators and cannot happen with state machine replication. - - - - -Empirically from approximately four years of PBFT permissionless networks in the wild, there is scant evidence of malicious writes to a database. One possible explanation for this may be the fact that chains are built by "walking" from a trusted root. All known blockchains using PBFT require starting up from a "genesis set". And usually this involves participating in a community (usually a company) and developing offline reputation. In few such networks are the validators anonymous. - - - - -Moreover, in PBFT there are games outside of consensus that increase the cost to authenticate (create reputation), such that amplification of attacks from performant malicious nodes becomes more costly. Systems can add other costs which then work in concert to create unsustainable costs for the attacker. There are a broad range of experiments in this area related to reputation, validator set accession, and disincentives for malicious behavior. - - - - -Mitigating attacks is not obviously mapped to economic costs. And economic costs will not exclusively deal with those attacks. Any analysis of cost paid for security versus the estimated dollar value of a safe transaction to send, are hampered by the noise of the effects of the reputation layer, which is very varied in the field. - - - - -Reputation and validator admission are high hurdles in PBFT chains, which is very different from Nakamoto consensus (which assumes no trusted root). But given that many of the security guarantees are arguable coming from "walking the graph", it seems that there may be optimizations in reducing the overpayment.ย ย  - - - - -The validators must receive a payment for their services. The challenge for all token holders is determining what is the correct fee to pay operators given that a) validator opportunity cost is extrinsic to chain b) the validators preferences (utility) is private. - - - - -If blockchains underpay, trust from the users goes down as fewer nodes participate. As a result, the security guarantees for halts and writes go down, and the subjective political neutrality of the chain is lowered. While perhaps a reasonable but imperfect assumption, that more payment always increases security, the designers of blockchain economics usually err on the side of overpaying for consensus. - - - - - -``` -This is the end of Part 1. [In Part 2](http://openlibra.blog/2022/10/20/proof-of-fee-part-2-a-proposal/), we will explore the mechanics and implementations of an alternative approach, Proof of Fee. -``` diff --git a/docs_old/archive/canonical/technical/proof_of_fee_part_2.md b/docs_old/archive/canonical/technical/proof_of_fee_part_2.md deleted file mode 100644 index e2580e59..00000000 --- a/docs_old/archive/canonical/technical/proof_of_fee_part_2.md +++ /dev/null @@ -1,648 +0,0 @@ - - -``` -In [Part 1 of this paper](http://openlibra.blog/2022/10/15/proof-of-fee-part-1/) we laid the foundations for Proof of Fee. Some of the ideas expressed there may be different from what you have seen elsewhere, and we do urge you to read that before you begin here. In Part 2 of this paper, below, we get into the mechanics and implementation details of Proof-of-Fee (PoF). -``` - - - -From empirical evidence over the last five years, we have seen few malicious attacks by validators; clearly something is working. We don't want to break something that is working. What we want to evaluate is whether we can make it sustainably work at a lower cost. - - - - -## Gaming it out - - - - -In part 1, we concluded that estimating the security of the network in monetary terms is not directly correlated to the financial costs of stakes. PBFT as a consensus algorithm has compelling built-in security properties. Plus, launching a PBFT network necessarily starts from a root of trust, and this can be reinforced by validator admission policies that reduce likelihood of Sybil attacks. - - - - -The central question is this: How is a large bond staked by a diverse group of agents contributing to security? Is it really necessary? - - - - -Before we can evaluate how the high bonding works on PBFT, we should define which actors can be Byzantine. Are we trying to be safe from the everyman who goes rogue, or a madman? The deterrence strategies you would apply in those two situations are not the same. - - - - -If you goal is educating the initially honest validators on what is expected, then we would argue that swift and sure penalties are much more important than highly severe but rare penalties. When it comes to madmen, however, economic guarantees are marginal at best. - - - - -### Deterrence is in the mind - - - - -Swift and sure penalties train actors in cause and effect and teach what is expected. A quick time-out is a much better training method for wayward children than a rare but severe strapping.ย  In theory, high stakes penalties for unlikely events are a way of achieving compliant behavior without having to wait for the parties to learn (by way of experiencing the penalties) but they work mostly through perceptions and may easily backfire. The rare strapping, for example, may teach the child that punishment is random and parents are not to be trusted.ย  - - - - -Similarly, capital punishment is a pyschological game, not a device meant to train someone across a series of events. Moreover, for something as extreme as capital punishment to work well, it needs to be placed within a context of other swift and sure penalties. That is, the credibility of maximal punishment also depends on consistency. Catch people for spray painting graffiti and others may be deterred from more serious crimes, but let graffiti take over and all punishment will come to be doubted no matter the crime. - - - - -Punishments for unlikely events work within a context of swift and sure penalties for smaller events mostly by preventing good agents from "breaking bad". Normal people learn what is expected and donโ€™t doubt that big deviations will be punished. - - - - -Severe penalties donโ€™t necessarily deter people that don't evaluate the punishment in the same way (e.g., the mentally ill, the North Korean nuclear program), or engage in a repeated game with the state where the punishment is not dispensed (e.g., serial killers, organized crime, Iranian nuclear program). Policy designers may assume incorrectly that the only way to handle these situations is to ratchet rare punishments yet higher. Applying maximal punishment out of the context of learning may seem rational to deter a madman, but to the everyman it is terror and leads to distrust and learned helplessness.ย  - - - - -What does this mean for blockchain?ย  - - - - -An attack by a sophisticated and resourced or irrational malicious actor is not going to be deterred by high bonding. In practice, slashing is never complete because of the fear this creates in normal, and normally good, actors. As implemented in Tendermint, for example, a defector does not lose their entire stake in a single "slashing" event commensurate with the damage done because that would drive out good actors. Moreover, a well-resourced attacker knows this, and isn't particularly deterred (and in fact could subsidize a one-time attack with winnings along the way). The solution, however, isnโ€™t to slash more. - - - - -There are always madmen that want to see the world burn; economic guarantees are not effective against them. The only thing that deters the madman, at any price, is the validator admission policy, as we describe below. Modest, swift, and sure penalties will achieve what can be achieved and at lower cost than โ€œcapital punishmentโ€ style slashing. We should leverage this in our favor to secure PBFT blockchains, at the appropriate cost. - - - - -### A town of robbers is no town at all - - - - -There's another argument often advanced for high bonds: Humans are not inherently honest ergo, we should assume people on the internet are out to rob the chain. This may be a perfectly reasonable philosophy but, in the specific case of PBFT, it's unlikely to be destabilizing. - - - - -Silvio Micali has a thought experiment; it goes like this: Why would anyone move into a neighborhood or town where the vast majority of people were thieves? Certainly no good actor. In fact, not even the robbers would want to live there! These are places that, by definition, cannot exist. This is called the "honesty assumption" of PBFT and PBFT algorithm provides a guarantee. If you want to reorganize the already committed blocks, you'll need โ…”rds of the validator set to go along with it. Certainly it's possible that โ…”rds of the validator set could act against the will of one party or the entirety of the accounts on chain, but it begs two questions: (1\) How does a network even arrive to the point of having โ…” malicious actions? and (2\) Are we sure an honest community can't recover from this? - - - - -Since PBFT networks start from a root of trust and continue to reinforce the norms of behavior, it seems that the deterrent to this problem is not economic, but rather in the validator credentialing process. The ways this is implemented are diverse. Weโ€™ve seen multiple approaches, from a foundation or a company signing contracts (with testnet winners), or a decentralized vouching from the existing validators, or coin voting for validator admission. - - - - -Moreover, there is also a way for account holders to recover: They can fork the validators out. Forking is another deterrent to a cabal of malicious agents. If you reorg the blocks against the will of the account holders by creating a fork, it may be trivial for the account holders to continue from where the fork branched off, with a new validator set. This is considered "weak subjectivity", and informal in the eyes of certain blockchain designers, but it doesn't prevent it from being a real deterrent, since it only needs to exist in the mind of the malicious actor. All that effort by the madman will be for naught. (To be clear this property doesn't neatly generalize to all blockchain consensus algorithms). - - - - -### Cartels are unstable - - - - -Lastly, advocates of high bonding rates might say it's trivial to turn good actors bad โ€“ you can just bribe people to join a cartel. However, that argument fails to consider that bad agents also face challenges. Coordination in adversarial space is a hard problem and this also applies to malicious agents attempting to form a cartel.ย  - - - - -Cartels are not monopolists, though they try to achieve the maximum profit as if they were one. The trouble with cartels is that the dominant strategy of the cartel member is to cheat, not only once, but repeatedly. One defector from the cartel can reap the rewards of the monopoly price at a cost to other cartel members (not the consumer). And cheating in the repeated game quickly destabilizes the cartel. Plus, if your cartel operates outside the law or norms, is there any reason to expect a cartel member to respect the cartel's agreement? We know this from the behavior of other malicious cartels (think: drugs, mafia), which are rarely stable. The stable cartels that come to mind are those rare exceptions supported by governments (think: OPEC, American Medical Association). - - - - -So, if you are planning a long range attack on a blockchain, you'd better be sure that you are the monopolist and that you control all the nodes, otherwise you will be left holding the bag. This is a very expensive proposition, and likely loss-making. The cartel argument is a distraction; though one-time colluding attacks in PBFT can happen at a cost and uncertainty to the participants, sustaining collusion is another matter. - - - - -## Proof of Fee: Auctioning Consensus Seats - - - - -Given what we've seen above, a lot of the deterrence is already baked into the nature of the PBFT game and that deterrence is largely independent of the price. The madman attack is taken care of by admission controls, not economics. The cartel scenario is a red-herring. The economic guarantees seem to only be needed to keep honest peopleโ€ฆ honest.ย  - - - - -So our provocation is this: What's the optimal price for the *social surplus*, so that everyone wins? - - - - -Proof of fee (PoF) is based on a premise: Letโ€™s create equivalents of the bonding, staking, and slashing process by simply charging the equivalent cost of capital through an admission fee. - - - - -### Problem Definition - - - - -The PoF protocol assumes that all revenues to the chain belong to all the token holders. As such, transaction fees are not a property right of the operators (validators). We assume that blockchains intend to be self-sufficient (or better), where sufficient revenues exist to pay for the consensus costs. As discussed in Part 1, because future blockspace is likely to become abundant (due to engineering advances), the blockchain must either develop other revenue streams besides blockspace, or become more cost efficient. For the cost-conscious token holders, the key question is: For a given level of security, how much do token holders have to pay to validators? - - - - -### First Approach: A Reverse Auction - - - - -On all blockchains, nodes are competing in an auction of compute power. What if we turned the usual blockchain auction upside down? - - - - -Our first attempt at a delegation-less and stake-free economic system is a [reverse auction](https://en.wikipedia.org/wiki/Reverse_auction). Reverse auctions are also called procurement auctions, such that an enterprise has their orders for materials delivered at the lowest cost. In our case, the enterprise is the blockchain and the provider is the validator node. - - - - -One could set up an auction as follows: At the start of an upcoming epoch (period of blocks) a node which is selling compute power (to the blockchain for consensus) states the minimum reward they are willing to receive for the services at the end of the epoch. The X number nodes with lowest bids get admitted to the validator set. - - - - -The reverse auction model is attractive, namely for its simplicity. Alas, however, it is too simple. Simply agreeing to take a low fee, and subsequently being allowed to enter the validator set is not sufficient in permissionless and adversarial environments. We would really be pushing the limits on the guarantees of PBFT, since we really have the nothing-at-stake problem in this design. - - - - -The limitation of the above design is that there is no actual cost to enter the agreement with the blockchain. In such a simple reverse auction, the validator can bid a low fee but never deliver on services. In a group of carefully vetted operators, this would be fine. But in an adversarial scenario, or a scenario where the abilities of the validators are indeterminate (amateurs), there should be a real cost to non-performance.ย  We can imagine ways in which a madman might wreak havoc in a number of ways (a "split brain" attack for instance). But as we said above, preventing this belongs in the domain of the validator credentialing. The real threat is operator incompetence. Suppose a validator bids the maximal amount, and simply forgets to start the machine at the right time. This hurts the network in a meaningful way, it will slow down and ultimately halt, and at no cost to the validator. The risks are asymmetric, and leads to a type of prisoner's dilemma game. Empirically this has been the greatest threat to PBFT networks: Amateurism.ย  - - - - -### Pricing Carelessness With A Forward Auction - - - - -In almost all markets there are entry fees, some are explicit, and some are implicit. In Bitcoin, there is a hardware capital cost. In DPoS, there is a bond. How else can we charge an entry fee? - - - - -As a reverse auction is not ideal, we'll need to go back to an ordinary (forward) auction, where the blockchain is selling consensus seats. In this case, the validators need to know what they are bidding on, and know what the cost of non-performance is.ย  - - - - -The design is equally simple: The blockchain must determine the baseline reward it is willing to offer validators for the epoch, and validators pay to gain admission. - - - - -As an example, suppose the blockchain offers 10 coins per validator every epoch and suppose that the validator is profitable at 4 coins to validate (with 4 being the real dollar cost evaluated in coins at current dollar-coin exchange rates). Validators, functioning as bidders, would then bid on the seats in consensus, e.g. pay in advance up to 6 coins, for the benefit of winning 10, and thus netting 4 coins. This is functionally equivalent to the reverse auction where the validator would bid 4 coins. The difference is that the node is bonded within the epoch. The payment to get a validator seat is final. So if the validator does not perform, their admission fee is lost and they lose 6 coins. Thus, this auction format is the equivalent in DPoS of "slashing" a part of the bond. - - - - -The bond may seem low, but remember our thesis: We are only trying to keep honest actors from turning bad, and also not encourage careless operators with asymmetric risks.ย  - - - - -The disadvantage of this model is that the blockchain must set the baseline reward wisely (10 coins in the above example). If the baseline is set very wrong, it can create an uncompetitive auction. We discuss this issue further below. - - - - -### Thermostatic Baseline Price - - - - -How can the baseline price stay within a range in which the bidders are motivated to participate, given the external market conditions? If one sets the baseline too high and not enough biders show up, the network may dilute or exhaust their reward subsidies. If the baseline becomes too low, then no bidders show up. - - - - -Suppose the baseline reward to validators is set too low, given extrinsic market conditions. Such a situation does not create a large implicit bond, and thus does not create an effective deterrent. For example, suppose that instead of setting the baseline reward at 10 in the above example, the reward was set to 5\. Now validators will bid up to 1 for the right to earn 5 but this means that a validator that fails to validate loses only 1\. Worse yet if the baseline reward falls to less than 4 then eventually no validators show up. To solve for this, a โ€œthermostaticโ€ solution could be applied: as in home heating devices, the heat increases or decreases by a certain amount to target a given temperature.ย  - - - - -Letโ€™s look at an example. Let the baseline reward be BR and the cost of validation C then validators will bid up to BR-C to enter the validation set. To simplify notation we can assume that C contains an opportunity cost of capital so that if bidders are paid C they are earning a normal profit. In this case, in a competitive market, bids will rise until Bid\=BR-C. (Recall from the previous example that BR was 10, C was 4 and bids rose to 6\). The bid is also the equivalent bond since it is the bid which may be lost by failing to validate. Now from this perspective, there is an easy solution to setting the baseline reward: Set it absurdly high, say 1000\. In this case bids will rise to 996 and validators will be extremely careful never to fail to validate since the bond is 996\. The problem with this simple solution is that the higher the bond the greater the rewards to collusion and the more risk is imposed on validators. The competitive price in this scenario is 996 but even minimal collusion that brought the price down to say 900 would create very large profits and thus this model is asking for collusion. Even without collusion there may arise a situation where, for accidental or unusual reasons, there are only a handful of bidders who bid say 900 or less and thus they win the rights to earn 1000 for a pittance. In addition, a very high bid/bond means that an error on the part of the validators (โ€œtrembling handsโ€) subjects them to large losses. Risk aversion may then dissuade bidders from bidding which in turn could make collusion easier. High fees could thus potentially put the network at risk. Low fees, however, result in too few bidders as we noted above. - - - - -Thus, the protocol must target a bid (BR-C) which is large enough to promote good and careful behavior on the part of the validators but also small enough to not induce collusion and to withstand โ€œtrembling hands,โ€ i.e. small errors in competitive behavior or execution. Fortunately, there is a very large range under which these conditions are satisfied. Thus, the targeting need not be precise. - - - - -Essentially we want the bid to be large enough so that poor performance hurts but not so large as to deter bidders for fear of losing the bond nor so large as to encourage collusion. Itโ€™s likely that a bond greater than 2C would be enough which would mean BR-C\>2C or BR\>3C and BR\>5C would be plenty so we would target a baseline reward (BR) at 3 to 5 times validator costs. Costs (including opportunity costs) donโ€™t vary much over time so this could be set slowly.ย  - - - - -There are a few ways this could be implemented. Some blockchains may find it acceptable to set this manually through governance (one or two times a year), though this just creates another issue to quarrel about. It's possible an oracle could be used to target an extrinsic price signal, i.e. the dollar price of the reward. Though we would prefer on-chain algorithms. - - - - -A simple algorithm could be implemented that when the bids are persistently near 100% or 0% of the reward then the baseline may increase or decrease by N coins in the following epoch. Alternatively, something more straightforward may be possible: Target BR so that the number of bidders relative to the validator set is always large and well above the validator set. That is, BR would rise as the number of bidders fell and fall as the number of bidders rose. Again, the precision does not matter, so long as BR doesn't fall out of range for a prolonged period of time. - - - - -Note again, that because the bidders will bid more when the BR rises there is little to no danger in a large BR so long as there are many bidders and we avoid situations where BR is so high that the network cannot afford accidental large payments. - - - - -The numbers, above, are illustrations. The actual numbers would need to be experimentally tested and paired with thermostatic adjustments to properly tune the design space. - - - - -## Implementation Details - - - - -### Limited Validator Set Rotation - - - - -The auction should not be used to replace the entirety of the seats in the validator set. For example, if there are 21 seats available, and there are 100 candidates for the seats, it wouldn't be prudent to allow all the 21 seats to be replaced by highest bidders from the 100 candidates.ย  - - - - -Theoretically, the problem here is that a sufficiently well funded adversary, with no experience (or perhaps even the hardware) could completely halt the network simply by creating accounts and funding them. While we think madmen scenarios are unlikely, this would just be an invitation to them.ย  - - - - -As we discussed above, operator error is the most common threat, (ou may have โ…“ of the nodes that simply were not ready, or were hit by a data center outage, or failed to upgrade, or were asleep, etc.). This problem also exists in PoS blockchains, and the most common solution to this as observed in the field is to limit the validator rotationย  - - - - -In practice this means limiting the amount of turnover between one epoch and the next for exactly this reason. In PoF, we would have to accommodate for this as well. For example, no more than โ…“ of the new incoming validators can be of unknown "readiness". (Practically, it should be a lower number than one third to accommodate for 2f\+1 errors where you might be putting your network really at the borderline of forming consensus. So perhaps ยผ is better.) - - - - -Fortunately the solution is straightforward for PoF: Rank the maximum bidders of outgoing and prospective sets, and drop the bottom โ…“ validators from outgoing set to open up for the prospects.ย  - - - - -Assuming epoch E1 and E2, and a prospective validator universe P, which is a set of all bidding validator candidates, and the respective epoch validators V1 and V2\. We first fill the two-thirds of cardinality of V2, i.e,ย  โ…” \* V2, with *the* highest bids of V1, called continuing, denoted by C. Then we fill the set of (V2-C) with the ranked bids of P excluding C the continuing validators.ย  - - - - -This way the union is always maximizing for the highest bidders, and not endangering the network for halts by operator unpreparedness. - - - - -Readers might ask, why not take the most reliable validators by some metric, and then auction off the remaining โ…“ of the seats? This leads to a couple problems: - - - - -1. You're introducing a vector for gaming. A validator that is consistently the best performing will rationally bid zero. And as such this opens a Sybil issue and malicious behavior can be rewarded. Moreover, the auction is not maximizing revenue. -2. More importantly, we don't have reliable metrics to use on-chain for this. We only really know who signed and who proposed the previous block at any time. If we create a target threshold from either of these points, we introduce other undesirable properties of a network that should be plausibly neutral. In PBFT there's one artifact of networking which would cause the validators that are in the nearest datacenters (by network ping) to propagate their proposals and votes faster. Thus, to rely solely on the ratio of signatures or proposals creates a race to centralization. - - - - -### The Seats Should Be Uniform - - - - -The product of the auction matters: Is it auctioning consensus power, or consensus seats of the same power? - - - - -The mechanism described above is notionally for multiple units of the same product: Seats in consensus. However, BFT consensus has another feature which is voting weights, or consensus power. Every block requires a quorum to be committed where quorum is two-thirds of total voting weight. A validator selection process needs to also address the weight of each vote in reaching consensus. In DPoS systems, stakers have theirย  "consensus weight" determined by the amount staked. The implication of a higher consensus weight is that the nodes are able to cast more "votes" on a block, and thus have an outsized role in consensus. Layered on top of that may be an economic reward for proposers (for example, the proposer bonus in Cosmos Hub). - - - - -In having different weights, especially when there is huge deviation, consensus would be reached faster by reaching a quorum with lesser participants. For instance, some PoS networks have 100\+ validators but only the top 5 make the quorum.ย  - - - - -Our current opinion is that all seats should be treated equally. Most BFT academic work, and deployment pre-blockchain, assume equal weights. Recent derivations, such as HotStuff, Narwhal, and BlockSTM, talk in terms of equal weight in their published academic work. It was with Tendermint and DPoS that the concept of weighting gained prominence (possibly because of an assumption that it would optimize the auction for seats by stake, which may not bear out). - - - - -We think that variable votes in consensus removes one of the important sybil resistance properties of the "madman" attack described above. That said there may be a reason a blockchain wishes to give greater weight to different nodes.ย  - - - - -Through entry fees, a node could be assigned relative weights depending on the price that they bid. That is, the nodes which forgo the most payment will have higher chances of qualifying for liveness. Conversely, the nodes whose hardware and operation constantly perform the highest, will likely be able to charge higher fees, since they are not at risk of being below threshold. Auctioning a โ€œliveness bonusโ€, so to speak, is a price signal, and there may be legitimate reasons why validators are needing to get a bonus (their nodes are harder to reach).ย  - - - - -Future research should decide if there is a meaningful optimization in having variable votes per seat, without compromising the security. Note variable votes per seat has important consequences for the auction mechanism (more detail below). - - - - -### Auction Formats - - - - -There are multiple auction formats that should be discussed. There's a risk in getting side-tracked in a discussion on auction mechanisms, but fundamentally, the big picture is simple: There's no auction mechanism that can correct for the absence of bidders. Ensuring an ample supply of bidders that always exceeds the number of validator slots is of first order importance.ย  - - - - -The auctioneer maximizes revenue mainly by having better products. And if the product canโ€™t be improved, the auction increases revenue by adding anotherย  marginal bidder. This needs to be highlighted: **Everyoneโ€™s effort is best spent on making a better product**. The only job of the auction designer is to eliminate the worst auctions, and then pick the auction that is easiest to understand by the bidder, and appears fair. This will increase the amount of bidders, and thus revenue. - - - - -In terms of picking the auction, the designer needs toย  prioritize certain features, as these decisions will impact your choice of auction format and configuration. Key issues impacting that choice are:ย  - - - - -* Whether to optimize for revenue of the chain? -* Should validators bid their true expected utility? -* Are seats uniform? -* What level of privacy is desired? -* Do we expect collusion from bidders? - - - - -The principal decision to be made is whether the product is "votes" in consensus or seats which are all equal. Above, we recommend seats with the same consensus weight, but we will give some notes below for the auction for votes scenario. - - - - -#### *If All Seats Are Equal* - - - - -The most important optimization as we say above is that the auction has to invite the most bidders, that is: It needs to be low friction, not require much analysis, and generally feel fair. - - - - -##### Vickrey-Clarke-Groves - - - - -The main constraint on the auction design is whether private bidding is possible. A sealed bid, (implemented with commit-reveal) may be possible, but is likely impractical for the workflows of operators. Assuming this was an acceptable position, we could make use of incentive-compatible Vickrey-Clarke-Groves auctions. There's a lot to be said about VCG auctions and their ability to surface bidder preferences in a truthful manner. In blockchain applications, however, this has been impractical, so we need to consider open auction formats. - - - - -##### Open Nth-Price Auctions - - - - -The simplest and most common auction type is a *first price auction*. Despite known tradeoffs Blockchains implement first prices often, and they seem reliable in adversarial environments. First price auctions can be conducted in the open. Bitcoin uses first price for transaction ordering. A [Generalized First Price Auction](https://en.wikipedia.org/wiki/Generalized_first-price_auction) has been historically used in online environments (ads), also for positional ordering, but it is difficult for bidders to discover optimal strategies and for these reasons is susceptible to manipulation (reducing revenue to auctioneer) based on its non-truthful properties. - - - - -A [Generalized Second Price Auction](https://en.wikipedia.org/wiki/Generalized_second-price_auction) (also a variation of a Vickrey Auction), seems similar to a Vickrey auction but is misnamed since the truthful properties of bidding are not always preserved in GSP. (VCG is the true generalized second price auction.) For similar reasons, the bidder has to work on figuring out where they are placed with other validators. In practice, it works reasonably well, however, and revenues are typically as high as in VCG. - - - - -##### Uniform price auctions - - - - -We recommend a single price auction for the case of uniform seats. ([Also called treasury auctions,](https://en.wikipedia.org/wiki/Single-price_auction) since this format is used in U.S. Treasury market operations.) The last ranked qualifying bid sets the price for all validators. - - - - -This may be counter intuitive, but even though everyone pays the *lowest* accepted bid the revenue to the auctioneer has been demonstrated to be similar to other auction formats such as the first price format in which everyone pays their own bid. In essence, under first price people shade their bids down but in a uniform auction bids are higher and it works out that on average revenues are the same. The major advantage of uniform-price auctions is that it's easier for the bidders to know what to do: They can bid their true preferences since they will never overpay. Gaming may not be worth the effort. It's an elegant solution, and very easily applied to blockchain contexts, though it would require that all seats have the same properties. - - - - -Uniform price auctions are usually done as a sealed-bid, however it appears that open auctions with repeat bidding, with bids that cannot be retracted (lowered), will approximate the revenue of sealed bids. A reserve price also helps prevent non-truthful bidding. - - - - -#### *If Selling Votes in Consensus* - - - - -In the case of auctioning variable votes in consensus we have multiple units of the product, and the bidder can buy multiple ones. Typically a [sealed multiunit auction](https://en.wikipedia.org/wiki/Multiunit_auction) would be recommended. Though we have the same privacy issues described above for VCG. The multi-unit auction and single price auctions have a winner take all problem, where one bidder can take all the votes available in consensus in a single bid: if you know the highest price you can outbid and take allย  votes available. - - - - -Given these issues we should consider nth-price auctions. A generalized first price auction (described above) would be the alternative to experiment with. This format gives the bidder the value that they were willing to pay. It is also practical for blockchain environments and can be played openly, but not perfectly susceptible to collusion with a limited amount of bidders.ย  If they were to pay a lower price than what they bid (as in a second price auction), the incentive is to vote only above the remaining votes, possibly shading the bid.ย  - - - - -### Negative Fees - - - - -Negative fees are possible, and might be allowed in PoF since they are a relevant price signal. As described above, if bidders are consistently on average bidding 100% of the reward, this means that the reward is low, and we might be losing validators because we are not paying the opportunity cost. If 100% was the limit, it would be hard to discover how much we are underpaying. That is, it might take longer for a thermostatic mechanism to adjust. Said differently: Thermostatic baseline pricing allows for negative fee price signaling. - - - - -Negative fees should be avoided if there is no thermostatic adjustment, due to the risk of making validators compete on MEV frontrunning. Validators may engage in frontrunning, and as such should pay for it โ€“ PoF allows for this. It becomes something of a detractor for those who try to gain an edge with MEV.ย  - - - - -In another situation, itโ€™s conceivable that MEV might become widespread, and negative fees would force validators who are not engaging in front running to do so in order to remain competitive. PoF is not a solution to MEV; this will eventually be resolved through engineering advances in transaction inclusion design (e.g. proposer and validator separation). Until this gets solved, the blockchain can monetize some of the MEV. - - - - -If negative fees are permitted, there must be lower bounds, even though negative fees means more revenue for coin holders until the thermostatic adjustment kicks in. Without limits, it would be trivial for a sufficiently funded Byzantine adversary to take all the seats (or consensus power depending on auction) in a given epoch. - - - - -## Discussion - - - - -### Ergonomics - - - - -The greatest benefit of PoF is that it is simple. Every actor has a very simple instruction on what to do: - - - - -* Holders: Just hold. You are losing nothing by being passive. -* Validators: Bid what it's worth to you. -* Apps: Developers can develop scenarios where the coin is used in the app, or held, without risking its loss of value from dilution. - - - - -There are no secret handshakes, it doesn't require being able to become connected to capital to fund your stake. Historical DPoS networks have started by using a company or foundation sponsoring the initial stakes of validators (and this is often hidden information). PoF removes this out-of-band game. It not only provides an open opportunity to prospective validators, it's optimal for the network: The validators must compete on price, and not pre-existing business relationships. - - - - -### Bonding - - - - -The greatest question about PoF is if it is safe. Put differently, is the inter-epoch bond (the entry fee) a sufficient deterrent.ย  - - - - -In DPOS systems, very large bonds are placed to disincentivize, via the cost of capital of the parked coins combined with the threat of slashing. These costs appear to work. But to what extent is the cost too high? The bond and expense of a validator in DPOS is measured in the collateral and the expense of the cost of capital during the epoch. This cost can be orders of magnitude greater than the profit of the validator during the epoch. - - - - -The trap is that, in DPOS, the answer to the question of how much of a bond is needed is usually "more". Modeling this is an exercise fraught with assumptions. Above we argue that the baseline "'honesty assumptions" of BFT and the empirical evidence show that slashing large stakes is not needed. Notably, Avalanche blockchain is a Proof-of-Stake network without slashing. - - - - -PoF has no slashing except for losing the bid, which is effectively a bond. The question PoF asks is whether that bond needs to be 1,000X the profit, or if by slashing smaller stakes (i.e. the bid) repeatedly, if need be, we will have the same deterrence on less-than-competent validators. - - - - -### Delegation - - - - -A notable feature of Proof of Fee is that there is no delegation. Delegation in POS proposes to solve two issues: (1\) how to distribute rewards broadly, and (2\) how to have economic agents participate in validator selection. - - - - -#### *Less investor rent-seeking* - - - - -We assume with DPOS that all rewards are distributed to the "stakers" of the validator, and that a marginal fee (usually around 3-5%) is paid to the validator's operator. Historically, this means the initial stakes are set up by investors from conventional venture capital or, until about 2019, "retail" market ICOs. As we stated earlier, there are social effects to having this investor class receiving rents from future depositors. - - - - -In PoF, the principal property is that all coin holders are effectively stakers of the entire validator set. This is because PoF removes delegation and the investor class. While there are opportunities for capitalists in PoF, such as financing entry fees, this operates much more like a type of receivables financing rather than a preferred shares early investor financing. There could be no broader distribution of excess rewards. So, while PoF welcomes capitalist financing, it does not depend on it to get off the ground, and doesn't promise rents into perpetuity above and beyond what other coin holders receive.ย  - - - - -#### *Participation in Validator Selection* - - - - -Validator selection is an issue on PBFT chains. PoF and DPOS have similar issues when there is no mechanism for selecting validators beyond economics, i.e. the party with the most economic budget can join the validator set. - - - - -A PBFT network is born from a group of validators, and the social norms of those validators propagate to subsequent participants. In contrast, PoF leaves the question of validator selection open, allowing for variations of delegation to exist, for example: - - - - -* On-chain or off-chain vouching mechanisms for validators will be desired by most communities. -* Delegation, whereby validators may receive loans from different agents to pay for entry fees. -* A community may even be willing to risk adversarial nodes (e.g. MEV) in consensus for a while. We would expect that such behavior would quickly cease to be attractive as participants are outbid by honest agents. - - - - -The DPOS hypothesis is that the holders of coins are good estimators of validator "quality" for the network. This is actually a public goods provision problem: A free rider problem. Estimating the abilities and usefulness of a validator is valuable to the network, but someone must pay for it, and neither end-user nor validator has the incentive to pay to create that information.ย  - - - - -The DPOS hypothesis is that staking is a good heuristic. The trouble is that the game forces operators to have a distributed group of economic agents wager on which validator they should be a party to. Empirically, this leads to a race from operators to offer "rebates" and negative commissions to users. Additionally, in practice, many stakers are in fact passive and allow their virtual asset service provider (i.e. Coinbase, Binance, etc.) to choose the destination of the delegation (usually their own nodes). On the part of the account holder, this is a perfectly rational decision in response to asymmetric information about the blockchain's condition. It's not entirely obvious that there is a high signal from the stakers on validator selection. Do we really know if we are picking the best, most performant and honest validator set? There are commentators in the field that say that the opposite often happens. - - - - -#### *Delegation increases Costs* - - - - -Our hypothesis is that the cost of consensus is not only higher on non-staked depositors in DPOS, but also it is higher globally. That is, for the transaction fees of the chain to adequately cover the security budget of consensus, the fees need to be sufficient to cover the opportunity costs of not only the operator, but also of the stakers.ย  - - - - -This means that higher transaction fees are needed than in the absence of delegation, and this picture is further complicated when issuance is needed to supplant that deficit in transaction fees. Non-staked coin holders are disadvantaged by this design. - - - - -### Law - - - - -A final point to mention here is regulatory profile. This topic is of increasing relevance to actors in this sector and DPoS needs to be considered in light of what is known. There's a long discussion to be had on whether regulatory issues are outside of protocol or not, that is, should regulators be considered agents in your game and is regulation an attack vector. Regardless of your views on that, DPoS clearly has a heightened regulatory profile due to the presence of various approaches to pooling, lending, and equity that variations of DPoS apply. Proof of Fee and its cost to enter the service market is more distinct, in that it does not rely on overt capital pooling mechanisms. - - - - -## Conclusion - - - - -The PoF design is upside-down from mainstream blockchains: Usually the protocol determines the price that is right for each validator, and the validator can choose to enter the validator set. As such it needs to make assumptions about private information of the validator, and so the validator is left with a binary choice: Take it or leave it. Over the very long term this may approximate opportunity cost, but with the practice of most blockchains heavily weighting rewards to early participants, the blockchain usually errs on the side of overpaying for security. In PoF, the onus is on the validator to reveal the correct price of consensus. - - - - -The above proposal starts with the assumption that PBFT networks are theoretically resilient before economic guarantees are applied: They a) have a high bar for transaction reordering which is easily caught with cryptography, and b) walk a trusted graph of nodes from the genesis. As such those chains have a higher safety profile than Nakamoto consensus for many theoretical threats. As for economic guarantees, DPOS on PBFT is cheaper than PoW with Nakamoto consensus. - - - - -With PoF we may be able to make PBFT even more cost effective for the chain, by safely removing delegation, which adds costs and taxes the less-informed and the accounts that are otherwise restricted from staking. If anything, our conclusion is that DPoS may be a local maximum, and there is still further experimentation to be made on economic guarantees for PBFT consensus. - - - - -Proof of Fee, with its emphasis on reducing the cost of security to a market-driven minimum, provides a new mechanism for blockchains concerned with building sustainable business models and for those concerned with maintaining greater equity among the participants in their ecosystem. We think this is a first step to creating networks that the mainstream population actually want to belong to. diff --git a/docs_old/archive/canonical/technical/research_report_decentralizing_permissioned_blockchain_with_delay_towers.md b/docs_old/archive/canonical/technical/research_report_decentralizing_permissioned_blockchain_with_delay_towers.md deleted file mode 100644 index 59c95eab..00000000 --- a/docs_old/archive/canonical/technical/research_report_decentralizing_permissioned_blockchain_with_delay_towers.md +++ /dev/null @@ -1,17 +0,0 @@ - -This report, published 18 March 2022, looks at the Delay Towers mechanism that was pioneered and deployed in the 0L Network. - - - - -The article was co-authored by Shashank Motepalli and Hans-Arno Jocobsen of the University of Toronoto. We quote the original synopsis below: - - - - -Growing excitement around permissionless blockchains is uncovering its latent scalability concerns. Permissioned blockchains offer high transactional throughput and low latencies while compromising decentralization. In the quest for a decentralized, scalable blockchain fabric, i.e., to offer the scalability of permissioned blockchain in a permissionless setting, we present L4L to encourage decentralization over the permissioned Libra network without compromising its sustainability. L4L employs delay towers, -- puzzle towers that leverage verifiable delay functions -- for establishing identity in a permissionless setting. Delay towers cannot be parallelized due to their sequential execution, making them an eco-friendly alternative. We also discuss methodologies to replace validators participating in consensus to promote compliant behavior. Our evaluations found that the cost of enabling decentralization over permissioned networks is almost negligible. Furthermore, delay towers offer an alternative to existing permissionless consensus mechanisms without requiring airdrops or pre-sale of tokens. - - - - -\>\> [View the original article, with download link to full report](https://arxiv.org/abs/2203.09714) diff --git a/docs_old/archive/community/community.todo b/docs_old/archive/community/community.todo deleted file mode 100644 index 75356786..00000000 --- a/docs_old/archive/community/community.todo +++ /dev/null @@ -1,37 +0,0 @@ - -### Open Source Everything - - - - -The 0L project is radically open source in that every aspect of the project is open to community contributors. The software that operates the network is not managed by a foundation or by a governance token. Instead, the community manages the technical infrastructure by developing software and making pull requests. Where decisions are not reducible to software, open source-like workflows are used to define, complete and review diverse forms of labor. - - - - -### Hustle Karma - - - - -Many of the activities required to have a vibrant open source community can not be reduced to pull requests in a github repo. In order to ensure non-technical contributors have a place in 0L, the Hustle Karmaย boardย provides community members the opportunity to define missions, sign up to complete missions, review completed missions -- and to get paid for doing so. There is work available for community managers, project managers, designers, communications experts and more. - - - - -[Learn more about the Hustle Karma DAO](http://openlibra.blog/community/hustle-karma-dao/) \>\> - - - - -### Polycentric Programs - - - - -There is a special class of account in 0L called a community wallet. They can be automatically donated to and have the special properties intended for funding public goods. There are currently a number of community wallets with published goals, controlled by different organizations. These programs are actively funding the missions in the Hustle Karma board. Anyone can create a community wallet, and advocate for donations to steer community funds. The voluntary donations to the polycentric programs are how the community expresses its preferences for how goals are prioritized and resources are allocated. - - - - -[Learn more about the 0L Community Programs](http://openlibra.blog/community/community-programs/) \>\> diff --git a/docs_old/archive/community/community_programs.todo b/docs_old/archive/community/community_programs.todo deleted file mode 100644 index c726ef87..00000000 --- a/docs_old/archive/community/community_programs.todo +++ /dev/null @@ -1,244 +0,0 @@ - -Anyone can create a program, accordingly, this list can change. Check back here for an updated list of programs. - - - - - - - - - - - -#### A Good List - - - - -Supports a collection of non-profit and humanitarian organizations. Contributors can vote on the weighting. - - - - - -[Learn More\>\>](http://openlibra.blog/community/community-programs/a-good-list/) - - - - - - - -#### Application Studio - - - - -Newlab started this program to back teams that have clearly-defined plans to leverage 0L for applications with real-world, measurable impact and utility. - - - - - -[Learn More\>\>](http://openlibra.blog/community/community-programs/application-studio/) - - - - - - - - - -#### Danish Red Cross Humanitarian Fund - - - - -Under the auspices of Red Cross humanitarian principles, the Fund aims to improve outcomes for communities affected by humanitarian crises. - - - - - -[Learn more \>\>](http://openlibra.blog/community/community-programs/danish-red-cross-humanitarian-fund/) - - - - - - - -#### Deep Technology Innovation Program - - - - -BlockScience has established this Program to create a pathway for funding to the academic fields that technology and other crypto networks rely upon. - - - - - -[learn more\>\>](http://openlibra.blog/community/community-programs/deep-technology-innovation-program/) - - - - - - - - - -#### Human Rewards Program - - - - -A program to allow anyone that can verify they are human to receive some coins for some human work. - - - - - -[Learn more\>\>](http://openlibra.blog/community/community-programs/human-rewards-program/) - - - - - - - -#### Moonshot Program - - - - -Inspired by the well-known Xprize awards, we think large and meaningful rewards are necessary to materialize frontier technologies which are ambitious, speculative, and non-obvious. - - - - - -[Learn more\>\>](http://openlibra.blog/community/community-programs/moonshot-program/) - - - - - - - - - -#### Ongoing Full-Time Workers Program - - - - -The iqlusion FTW Program aims to collect ongoing donations, and redistribute those donations to any engineers working full-time on the 0L platform on a monthly basis (collectively the FTW). - - - - - -[learn more\>\>](http://openlibra.blog/community/community-programs/ftw-ongoing-full-time-workers-program/) - - - - - - - -#### RxC Research and Experimentation - - - - -The RadicalxChange Foundation has established this ย Research and Experimentation fund to advance new incentive structures. - - - - - -[Learn more\>\>](http://openlibra.blog/community/community-programs/rxc-research-and-experimentation-0l-fund/) - - - - - - - - - -#### Social Infrastructure Program - - - - -This program is designed to provide capital to fund a wide range of benefits to 0L members in alignment with the mission, vision and values of the community. - - - - - -[learn more\>\>](http://openlibra.blog/community/community-programs/social-infrastructure-program/) - - - - - - - -#### The Iqlusion Engineering Fund - - - - -This program will establish and compensate community members engaged in engineering work whether original work, maintenance, or review of the code. - - - - - -[Learn more\>\>](http://openlibra.blog/community/community-programs/the-iqlusion-engineering-program/) - - - - - - - - - -#### Tip Jar - - - - -A personal tip jar for the lead 0L developer, who has contributed thousands of hours of work to the project. - - - - - -[learn more\>\>](http://openlibra.blog/community/community-programs/tip-jar/) - - - - - - - -#### University of Toronto MSRG - - - - -This program seeks to attract funding to help support basic research \& discovery targeted at distributed ledger and blockchain technology as well as distributed systems in the long term. - - - - - -[Learn more\>\>](http://openlibra.blog/community/community-programs/university-of-toronto-msrg/) diff --git a/docs_old/archive/community/economics.todo b/docs_old/archive/community/economics.todo deleted file mode 100644 index c2ed1848..00000000 --- a/docs_old/archive/community/economics.todo +++ /dev/null @@ -1,27 +0,0 @@ - -### Labor Focused Economy - - - - -Most blockchain networks allocate most of their rewards to node operators serving as โ€˜security guardsโ€™ but fail to invest directly in the development, operations and maintenance of the application layer. In order to fund labor, capital is routed to community wallets managed by independent organizations and used to fund technical and non-technical missions within the 0L ecosystem via [Hustle Karma](http://openlibra.blog/community/hustle-karma-dao/)ย board. Missions (also known as "[Community Programs](http://openlibra.blog/community/community-programs/)") are funded by community wallets currently receiving 50% of all validator rewardsย ย via autopay. This is an experiment in shifting the networks economic flows to reward humans actively contributing where other networks rewards accumulate to comparatively passive infrastructure operators. - - - - -### Identity Subsidy - - - - -Another experimental economic concept in 0L is an identity subsidy offered to accounts which solve proofs of elapsed time using the [Carpe App](http://openlibra.blog/technology/carpe-desktop-app/). The stack of proofs is called a tower, by building a tall tower you can demonstrate that your account is a persistent identity. Persistent identities help defend against Sybil attacks because building a longstanding history and even a reputation is possible while remaining pseudonymous. Additionally, accounts which submit proofs share in a pool of rewards. This mechanism ensures early adopters get access to gas so that they build, test and use the applications being developed on the 0L blockchain. - - - - -### Thermostatic Security - - - - -The 0L network is a fork of network optimized for 100 validators. As such, the 0L network prefers to have about 100 validators. Validator rewards decrease as the number of validators rises, and at 100 validators rewards reach a floor. In expection there will be 100 validators serving the network and their rewards will come primarily from gas paid for transactions on the network. At genesis, in order to avoid a flood of validator farms, an address must be oboarded to the validator set by a validator, and each validator can only onboard a new account once per two weeks. The number of candidate validators grows by a power of two every fortnight, at steady, it is expected anyone wishing to operate a node will easily find a peer to sign them in. diff --git a/docs_old/archive/community/governance.todo b/docs_old/archive/community/governance.todo deleted file mode 100644 index 6ac4ad32..00000000 --- a/docs_old/archive/community/governance.todo +++ /dev/null @@ -1,52 +0,0 @@ - -We feel strongly that building a community-led protocol requires community engagement in all aspects of the community and protocol governance. While the eventual goal is to launch on-chain community governance, our bottom up vision of community engagement needs to be validated to the extent possible before investing the time, effort and energy required to create the tools needed for on-chain community governance. To achieve our vision of true community governance, itโ€™s crucial that the ecosystem transition to full stewardship of the protocol and its development as soon as possible, without waiting for the creation of the tooling needed for on-chain governance, and in doing so, validate, test and improve our processes in a fluid and flexible environment, with the participation of the community.ย  - - - - -To provide some context: - - - - -## **Where we started** - - - - -The 0L Network launched with the simplest of governance structures in place, that is, onchain governance for the protocol, wherein the only voters are the validators. The project had no foundation, no DAO, no community governance structure. As an exercise in pure decentralization, it was left up to the community to chart the path to a sustainable project governance model. - - - - -## **Where we are now** - - - - -In January of 2022, the community adopted a proposal to implement MVP community governance. The MVP process took the form of coordination of effort via a set of working groups. As the illustration below shows, the working groups were organized topically, with two of the groups serving meta functions. - - - - -![](../../assets/wg-org-chart-example.png) - - - - -The meta working groups provided coordination between the groups as well as a mechanism for escalating proposals and conflicts. The rules governing this process were codified in the [0L Parliamentary Procedures](https://handbook.0l.network/index.php?title=Parliamentary_Procedures).ย  - - - - -While the working group process has been functional for coordination of tasks and general community matters, it falls far short of actual community governance as onchain protocol governance still resides exclusively in the hands of the validators. Moreover, there is no signalling mechanism or other device for informing the validators about the communityโ€™s wishes on particular matters.ย  - - - - -## **The 0L Network Constitution** - - - - -On 3 May 2022, the community voted to adopt the 0L Network Constitution, which lays out the Communityโ€™s foundational values. The creation of the Constitution was a major step towards establishing a decision framework and value system that can serve as the projectโ€™s north star as we move forward. You can [read the Constitution here.](http://openlibra.blog/community/governance/the-0l-network-constitution/) diff --git a/docs_old/archive/community/hustle_karma.todo b/docs_old/archive/community/hustle_karma.todo deleted file mode 100644 index c8705140..00000000 --- a/docs_old/archive/community/hustle_karma.todo +++ /dev/null @@ -1,60 +0,0 @@ - - - - -## View Hustle Karma Missions - - - - -This list is updated regularly and changed frequently. Check back to stay current or bookmark the page.ย  - - - - - - - -[View missions](http://openlibra.blog/bounties-by-category/) - - - - - - -Economics mechanism design is principally concerned with the allocation of resources. If you read our previous paper on [Economic Principles](http://openlibra.blog/2021/11/16/future-proofing-the-economics-of-blockchains-pts-1-2/), you remember this one: Allocate the correct resource. - - - - -This network values labor, and it demonstrates it by allocating to labor. This is radical. It will look and feel different from other networks, which have over-indexed on capital and influence. Capital and influence always follow skilled labor. Knowing this, It is critical for the community to innovate and to push boundaries on how work can be done, recognized and compensated in a decentralized way. - - - - -There is no centralized safety net here! There is no foundation that's going to contribute funds from outside the economy to get work done. The economic power to build this ecosystem comes from the many toiling within it. That wonโ€™t be easy; we need to keep pushing to get this right. - - - - -The Hustle Karma DAO is the first of many steps towards a productive yet decentralized labor force. The DAO is a project-management collective. Not just computers running a peer-to-peer protocol, but a group of human peers defining and operating and participating in granting programs according to their perception of what activities will make the ecosystem stronger. - - - - -The DAO is a project-coordination collective. The structure is simple and there is room for growth. People can submit tasks that should be done, and the existing programs, or even individuals, can choose to add bounties for those tasks. Other Karma DAO members may curate the tasks, pitch them to community members, track work done, and ultimately confirm to the bounty provider that the task is complete and ready for the bounty to be released. These tasks as well can be bountied. - - - - -For expediency, the DAO operates initially from an Airtable database. One of the first projects is to turn that database into a Smart Contract running on-chain. How meta. Thereโ€™s plenty of work to be done and itโ€™s not all software engineering; there are also jobs for Discord moderators, graphic designers, data scientists, technical writers, translators, and more. - - - - -We need to celebrate the work that goes into making a decentralized network possible. It starts by recognizing and compensating the diverse forms of labor required for it to thrive. Let us be more than mere peers in a computer network, but also peers in a collaboration network. As peers at work, we must make it as easy and natural as possible to share in the burdens and the benefits alike. Years of work have already been contributed, but in a living ecosystem there will always be more to do. The essential workers in an economy are just that, workers. With the labor flywheel turning, there is no stopping this network. - - - - -ย  diff --git a/docs_old/archive/econ/a_brief_overview_of_system_policies.md b/docs_old/archive/econ/a_brief_overview_of_system_policies.md deleted file mode 100644 index b7770b15..00000000 --- a/docs_old/archive/econ/a_brief_overview_of_system_policies.md +++ /dev/null @@ -1,154 +0,0 @@ -As you can see in our write ups elsewhere, we do things a little differently around here: we had no venture investors, there is no premine, no foundation with tokens, and anyone with a laptop can participate and earn coins. - - -Here's a quick reference to the policies implemented at genesis, with further discussion below. - - -## Rewards - - -* Rewards are paid at the end of each "Epoch", daily at 16:00 UTC. -* The majority of the rewards will go to Validator Nodes, you'll need a cloud host to be successful at this (you can't do this with a laptop, and you need to be somewhat technical). Transaction fees are the principal source of rewards, but they can be augmented by Guaranteed Minimum subsidies. -* End Users (who are not Validator Nodes), can receive an Identity Subsidy for creating durable identities through Delay Towers. This is a system "mining pool". - - -## Requirements - - -* We do not do Proof of Stake, instead preventing Sybil accounts is done through Delay Towers, a sybil resistance technique we invented. -* It uses Proofs of elapsed time which are done by theย `tower`ย app on cloud machines, or theย `carpe`ย desktop all for end users -* Validators are required to build Delay Towers, they must produce 6 delay proofs per day in order to gain admission to the validator set, and also to remain. -* End Users can optionally build Delay Towers to establish a persistent identity (and perhaps later join as a validator), and there is a reward for that. - - -## Validator Rewards - - -* Securing the network is done by a maximum of 100 delegations of "Validator Nodes". This is very valuable work to the network. -* At the start of the network each Validator Node has typically 1 entity or person behind it (a delegation of 1\). -* To become a candidate for a Validator Node, all that is required is to run the configuration tool, and to have any existing Validator in a current validator set send an onboarding transaction. (it's not a vote by the validator set to include a new validator.) While it doesn't take group permission to onboard a new validator, existing validators are rate-limited from creating endless accounts. They can only onboard a new prospective validator every 14 days/epochs. -* The budget for Validator subsidies is "thermostatic", it goes up or down depending on the total number of Validator Nodes doing work successfully. - - - + If the network is about to fail, with only 4 nodes on the network, the budget the network has for security, exactly 8,400,000 coins (the maximum). The 4 nodes share the 8,400,000 coins, 2,100,000 each. - + On the other extreme, when the network is reaching its technical performance limit, there is no reason to subsidize Validators. At 100 Validator nodes, the total budget is 0, and the 100 validators will share the transaction fees the network produces. -* The validator subsidy only exists in the absence of sufficient transaction fees. It is a Guaranteed Minimum, which is net of transaction fees. So hypothetically if the network has 4 nodes, and hence the security budget is 8,400,000, however the total transaction fees are already above this number (e.g. 10,000,000\), there is no need to subsidize the guaranteed minimum, there are no new Coins minted. This prevents unnecessary inflation. - - -## End Users Mining - - -* Anyone with a laptop and with an ordinary account (End Users) can receive coins for creating a Delay Tower (proofs of elapsed time), as a basis for durable identity. We also call this mining. -* At genesis the protocol provides a subsidy for end users building up their identity. The reward pool for all miners is exactly the equivalent of one Validator Node's rewards in a given day. This can be thought of as a single system subsidized "mining pool". -* It is a smaller reward compared to Validator Nodes. So, end users are encouraged to run Validator Nodes or pool together to share rewards of validator nodes. Future mining pools are up to the community to design and create. -* While End User account receive relatively smaller amounts of coins for the Identity Subsidy, their accounts have no restrictions on transferability, - - -## Transferability - - -* There are no restrictions on ordinary 0L accounts (end user accounts). -* There are voluntary restrictions people can place on their account: Slow Wallet and Community Wallet tags. - - -### Slow Wallets - - -* Early participants of a network may receive generous subsidies, but they are prevented from dumping on less sophisticated users, these are Slow Wallets. All validator node accounts, where a majority of rewards flow to must be Slow Wallets. -* At genesis Slow Wallets currently cannot transfer Coins between accounts. At epoch 100, they get 10,000 coins unlocked per epoch (day). - - -### Community Wallets - - -* Community wallets are optional settings which allow greater transparency, and also allow owners of the account to help prevent fraud. This designation of wallet is useful for anyone wishing to set up a program for the community benefit. And it also appoints all addresses in the validator set to be observers of the wallet, and they can slow down transactions by vertoing. With sufficient Vetoes the transaction gets rejected. -* CommunityWallets can only make transfers to Slow Wallets. - - -## Autopay Sponsoring Programs in the Community - - -* Autopay aims to make it trivially easy for early coin holders to send to development programs within the community. At this stage of the network Autopay can only send to wallets tagged CommunityWallets, this is a benefit of being a community wallet. -* At time of writing, there are approx 12 programs that have elected to use CommunityWallets. -* Like most smart contract platforms, the 0L System requires spending of credits (GAS Coins) for running smart contract computations on the system. These resources are allocated according to specific rules encoded in the core logic of the system. - - -# Earning Credits - - -Anyone can earn credits for themselves by performing computational work on the system. No permission is required. - - -The OL network is a marketplace: of sellers of computation (Validators), and buyers of computation (End Users). The marketplace does not receive a fee. Instead the Validators receive the entirety of the Coins earned for the services performed. - - -Since the transaction fees may not be sufficient inducement for a seller of computation to join as a Validator, the network has Guaranteed Minimum Transaction Fee, which is subsidized in certain network conditions. - - -# Guaranteed Minimum Transaction Fee - - -At times when the network is insecure (with very few validators), the transaction fees flowing through the marketplace may not be attractive enough for a prospective seller of compute power to join. - - -The Guaranteed Minimum provides a baseline earnings which the Validator can rely on. A network Subsidy makes up the difference between what actual transactions fees were paid, and what is justifiable as a minimum payment. If the Guaranteed Minimum is 10 Coins given a network condition, but the transaction fees amounted to 3 coins, then the network creates new credits amounting to 7 Coins, and thus pays the total of 10 to the validator. Supposing the minimum guaranteed calculated by the algorithm is instead 1 Coin per validator, and the same 3 coins were due from transaction feed, then the network does not create any new Coins, and pays the 3 coins to the validator (in excess of the 1 Coin the network considered a justifiable minimum). - - -The network's operating software encodes a schedule of the minimal accepted earnings given certain network conditions. The formula is intentionally simple. - - -When there are four validators on the network (near failure) the guaranteed minimum is at its highest. When there are 100 validators on the network, (the transaction throughput is exponentially diminished beyond that amount in BFT networks) the network has excess compute power, and the minimum guaranteed is zero Coins. This means that at 100 validators the validators should expect to earn only the transaction fees flowing through the network. For easy comprehension by prospective validators the schedule is a straight line from 4 to 100 validators. - - -This Auction aims to ensure the network always pays for security when it needs it, but does not overpay when it is not necessary to do so. It will appear generous at times, and miserly at others, but it should attract the necessary users. - - -Note, these allocation rules make some assumptions about BFT, that there is a super majority of honest actors and that the most committed validators are included in the validator set (proof of weight from Delay Towers) - - -# Identity Subsidy - - -0L's identity subsidy sybil resistance mechanism relies on Validators creating Delay Towers which provide a persistent, and non-forgeable identity. - - -It is important for the network to have as many users as possible creating durable identities, i.e producing Delay Towers. It has a number of benefits: allowing users not yet set up as validators to create identities, allows fullnodes to receive some compensation for providing replication services, and allows the VDF delay mechanism to be tested in a wide variety of hardware configurations so that the difficulty can be periodically adjusted. - - -While these activities are useful and deserve a meaningful subsidy, they are also low effort and cannot compete with the earnings to Validators (which are critical). This work is also less useful as the network matures, and has higher security (from Validator participation). Also the identity subsidy is highly gameable, and can lead to exploits by sophisticated users. The economics are designed such that those sophisticated users will be incentivized instead to run Validator nodes. - - -To balance the needs of validators, and exploits possible, miners thus share the equivalent of 1 Validator's Guaranteed Minimum in every epoch. The identity subsidy is an example of a "mining pool", where the end users share the rewards of one validator node. At genesis the protocol is sponsoring this single mining pool. We expect future mining pools to be an emergent property of the network, as end users seek to receive more rewards, from naturally diminishing rewards to the single system mining pool. - - -# Transferring Credits - - -Transfers of credits are unlimited for End User accounts (plain accounts). If an End User is running a "miner" and creating a tower, those credits are freely transferable. - - -There two categories of accounts that have opt-in rules for transfers - - -## Community Wallets - - -These are wallets that have elected to have community oversight. If a person or entity would like to increase the credibility of that wallet (e.g to create a program), they may opt to have the transfers be slowed down or ultimately rejected. More details here: - - -Community wallets typically will receive funds from AutoPay, if anyone wishes to automatically donate a % of their credits. - - -Sending automatic payments is easy. It is also encouraged socially. On the current network Validator Nodes are voluntarily opting into donating on average more than 50% of their rewards. - - -## Slow Wallets - - -Since transferring credits by early users can cause undesirable effects (e.g. creating markets and dumping credits on lesser informed users), the earliest members, and the ones most likely to accumulate large amounts of credits are rate-limited in transferring funds. Transferability also interferes with the ability of the auction for security. - - -The exception is transferring credits to Community Wallets. Those transfers are unlimited. - - -There are accounts that have elected to have restricted transferability. Those are designated Slow Wallets. To join a Validator Set a prospective user must have a Slow Wallet. diff --git a/docs_old/archive/econ/the_rulebook_at_genesis.md b/docs_old/archive/econ/the_rulebook_at_genesis.md deleted file mode 100644 index df744f07..00000000 --- a/docs_old/archive/econ/the_rulebook_at_genesis.md +++ /dev/null @@ -1,147 +0,0 @@ -As you can see in our write ups mentioned above, we do things a little differently around here: We had no venture investors, there is no premine, no foundation with tokens, and anyone with a laptop can participate and earn coins. Here's a quick reference to the policies implemented at genesis: - - -### Rewards: - - -* Rewards are paid at the end of each "Epoch", daily at 16:00 UTC. -* The majority of the rewards will go to Validator Nodes, you'll need a cloud host to be successful at this (you can't do this with a laptop, and you need to be somewhat technical). Transaction fees are the principal source of rewards, but they can be augmented by Guaranteed Minimum subsidies. -* End Users on the other hand, can receive an Identity Subsidy for creating durable identities through Delay Towers. This is a system "mining pool". - - -![](https://siasky.net/TAAnqdoTyTo8vyr82sWC_bO9CpRUJ7oFU-v4l7PFSng94A/rewards.png) - - -### Requirements: - - -* We do not do Proof of Stake, instead preventing Sybil accounts is done through Delay Towers, a sybil resistance technique we invented. -* It uses Proofs of elapsed time which are done by the \`tower\` app on cloud machines, or the \`carpe\` desktop all for end users -* Validators are required to build Delay Towers, they must produce 6 delay proofs per day in order to gain admission to the validator set, and also to remain. -* End Users can optionally build Delay Towers to establish a persistent identity (and perhaps later join as a validator), and there is a reward for that. - - -### Validator Rewards: - - -* Securing the network is done by a maximum of 100 delegations of "Validator Nodes". This is very valuable work to the network. -* At the start of the network each Validator Node has typically 1 entity or person behind it (a delegation of 1\). -* To become a candidate for a Validator Node, all that is required is to run the configuration tool, and to have any existing Validator in a current validator set send an onboarding transaction. (it's not a vote by the validator set to include a new validator.) -* While it doesn't take group permission to onboard a new validator, existing validators are rate-limited from creating endless accounts. They can only onboard a new prospective validator every 14 days/epochs. -* The budget for Validator subsidies is "thermostatic", it goes up or down depending on the total number of Validator Nodes doing work successfully. - + If the network is about to fail, with only 4 nodes on the network, the budget the network has for security, exactly 8,400,000 coins (the maximum). The 4 nodes share the 8,400,000 coins, 2,100,000 each. - + On the other extreme when the network is reaching its technical performance limit, there is no reason to subsidize Validators. At 100 Validator nodes, the total budget is 0, and the 100 validators will share the transaction fees the network produces. -* The validator subsidy only exists in the absence of sufficient transaction fees. It is a Guaranteed Minimum, which is net of transaction fees. So hypothetically if the network has 4 nodes, and hence the security budget is 8,400,000, however the total transaction fees are already above this number (e.g. 10,000,000\), there is no need to subsidize the guaranteed minimum, there are no new Coins minted. This prevents unnecessary inflation. - - -### End Users Mining: - - -* Anyone with a laptop and with an ordinary account (End Users) can receive coins for creating a Delay Tower (proofs of elapsed time), as a basis for durable identity. We also call this mining. -* At genesis the protocol provides a subsidy for end users building up their identity. -* The reward pool for all miners is exactly the equivalent of one Validator Node's rewards in a given day. This can be thought of as a single system subsidized "mining pool". -* It is a smaller reward compared to Validator Nodes. So, end users are encouraged to run Validator Nodes or pool together to share rewards of validator nodes. Future mining pools are up to the community to design and create. - - -### Transferability: - - -* There are no restrictions on ordinary 0L accounts (end user accounts). But there are voluntary restrictions people can place on their account: Slow Wallet and Community Wallet tags -* Though End users accounts receive relatively smaller amounts of coins for the Identity Subsidy, their accounts have no restrictions on transferability. -* Slow Wallets - + Early participants of a network may receive generous subsidies, but they are prevented from dumping on less sophisticated users, these are Slow Wallets. All validator node accounts, where a majority of rewards flow to must be Slow Wallets. - + At genesis Slow Wallets currently cannot transfer Coins between accounts. At epoch 100, they get 10,000 coins unlocked per epoch (day). -* Community Wallets - + Community Wallets are optional settings which allow greater transparency, and also allow owners of the account to help prevent fraud. This designation of wallet is useful for anyone wishing to set up a program for the community benefit. - + And it also appoints all addresses in the validator set to be observers of the wallet, and they can slow down transactions by vetoing. With sufficient Vetoes the transaction gets rejected. - + Community Wallets can only make transfers to Slow Wallets. - - -### Sponsoring Programs in the Community: - - -* Autopay aims to make it trivially easy for early coin holders to send to development programs within the community. -* At this stage of the network Autopay can only send to wallets tagged Community Wallets, this is a benefit of being a Community Wallet. -* At time of writing, there are approximately 12 programs that have elected to use Community Wallets. - - -## Background - - -Like most smart contract platforms, the 0L System requires spending of credits (GAS Coins) for running smart contract computations on the system. These resources are allocated according to specific rules encoded in the core logic of the system. - - -## Earning Credit - - -Anyone can earn credits for themselves by performing computational work on the system. No permission is required. The OL network is a marketplace: of sellers of computation (Validators), and buyers of computation (End Users). The marketplace does not receive a fee. Instead the Validators receive the entirety of the Coins earned for the services performed. - - -Since the transaction fees may not be sufficient inducement for a seller of computation to join as a Validator, the network has Guaranteed Minimum Transaction Fee, which is subsidized in certain network conditions. - - -## Guaranteed Minimum Transaction Fee - - -At times when the network is insecure (with very few validators), the transaction fees flowing through the marketplace may not be attractive enough for a prospective seller of compute power to join. - - -The Guaranteed Minimum provides a baseline earnings which the Validator can rely on. A network Subsidy makes up the difference between what actual transactions fees were paid, and what is justifiable as a minimum payment. If the Guaranteed Minimum is 10 Coins given a network condition, but the transaction fees amounted to 3 coins, then the network creates new credits amounting to 7 Coins, and thus pays the total of 10 to the validator. Supposing the minimum guaranteed calculated by the algorithm is instead 1 Coin per validator, and the same 3 coins were due from transaction feed, then the network does not create any new Coins, and pays the 3 coins to the validator (in excess of the 1 Coin the network considered a justifiable minimum). - - -The network's operating software encodes a schedule of the minimal accepted earnings given certain network conditions. The formula is intentionally simple. When there are four validators on the network (near failure) the guaranteed minimum is at its highest. When there are 100 validators on the network, (the transaction throughput is exponentially diminished beyond that amount in BFT networks) the network has excess compute power, and the minimum guaranteed is zero Coins. This means that at 100 validators the validators should expect to earn only the transaction fees flowing through the network. For easy comprehension by prospective validators the schedule is a straight line from 4 to 100 validators. - - -This Auction aims to ensure the network always pays for security when it needs it, but does not overpay when it is not necessary to do so. It will appear generous at times, and miserly at others, but it should attract the necessary users. - - -Note, these allocation rules make some assumptions about BFT, that there is a super majority of honest actors and that the most committed validators are included in the validator set (proof of weight from Delay Towers) - - -## Identity Subsidy - - -0L's identity subsidy mechanism relies on Validators creating Delay Towers ([https://siasky.net/EABaWAXFy3Ztx1vVIpOfScjkRaTb1GrFeGRwqFKd6V-hAg](https://siasky.net/EABaWAXFy3Ztx1vVIpOfScjkRaTb1GrFeGRwqFKd6V-hAg)) which provide a persistent, and non-forgeable identity. - - -It is important for the network to have as many users as possible creating durable identities, i.e producing Delay Towers. It has a number of benefits: allowing users not yet set up as validators to create identities, allows fullnodes to receive some compensation for providing replication services, and allows the VDF delay mechanism to be tested in a wide variety of hardware configurations so that the difficulty can be periodically adjusted. - - -While these activities are useful and deserve a meaningful subsidy, they are also low effort and cannot compete with the earnings to Validators (which are critical). This work is also less useful as the network matures, and has higher security (from Validator participation). Also the identity subsidy is highly gameable, and can lead to exploits by sophisticated users. The economics are designed such that those sophisticated users will be incentivized instead to run Validator nodes. - - -To balance the needs of validators, and exploits possible, miners thus share the equivalent of 1 Validator's Guaranteed Minimum in every epoch. The identity subsidy is an example of a "mining pool", where the end users share the rewards of one validator node. At genesis the protocol is sponsoring this single mining pool. We expect future mining pools to be an emergent property of the network, as end users seek to receive more rewards, from naturally diminishing rewards to the single system mining pool - - -## Transferring Credits - - -Transfers of credits are unlimited for End User accounts (plain accounts). If an End User is running a "miner" and creating a tower, those credits are freely transferable. - - -There two categories of accounts that have opt-in rules for transfers - - -### Community Wallets - - -These are wallets that have elected to have community oversight. If a person or entity would like to increase the credibility of that wallet (e.g to create a program), they may opt to have the transfers be slowed down or ultimately rejected. More details here: - - -* Community wallets typically will receive funds from AutoPay, if anyone wishes to automatically donate a % of their credits. -* Sending automatic payments is easy. It is also encouraged socially. On the current network Validator Nodes are voluntarily opting into donating on average more than 50% of their rewards. - - -### Slow Wallets - - -Since transferring credits by early users can cause undesirable effects (e.g. creating markets and dumping credits on lesser informed users), the earliest members, and the ones most likely to accumulate large amounts of credits are rate-limited in transferring funds. Transferability also interferes with the ability of the auction for security. The exception is transferring credits to Community Wallets. Those transfers are unlimited. - - -There are accounts that have elected to have restricted transferability. Those are designated Slow Wallets. To join a Validator Set a prospective user must have a Slow Wallet. - - -Carpe diem โœŠโ˜€๏ธ - - -ย  diff --git a/docs_old/archive/proposals/october_2022_governance_recap.md b/docs_old/archive/proposals/october_2022_governance_recap.md deleted file mode 100644 index 049894e5..00000000 --- a/docs_old/archive/proposals/october_2022_governance_recap.md +++ /dev/null @@ -1,222 +0,0 @@ -# October 2022 Governance Recap - -The 0L Community recently concluded its first round of collaborative, decentralized strategic planning. Starting first with rounds of guided discussion on the [RadicalxChange Voice](https://voice.radicalxchange.org/) platform, the process culminated with a set of eight proposals for community vote. In this blog post, weโ€™re going to take a brief look at the contents of those proposals and reflect on the outcomes of the vote.ย  - - - - -## The Voting Process - - - - -Seven of the eight proposals gave voters a yes\-or\-no binary option for voting. The eighth proposal was comprised of four parts that needed to be voted on independently. The voting platform was RadicalxChange Voice, which gives all voters an equal amount of โ€œcreditsโ€, which can be used to vote more than once for any proposal they feel strongly about, allowing them to express how committed they are to that result (note this factor is expressed below as โ€œvoting powerโ€ which expresses the total commitment of both positive and negative votes). Voters were not able to see the votes of the group as they cast their votes, and the voters could change their votes right up to the deadline.ย  - - - - -## The Proposals - - - - -### [Proposal 2210\-01 Final Supply](http://openlibra.blog/2022/10/11/proposal-2210-1-final-supply/) - - - - -**Synopsis**: Proposal 1022\-01 is focused on stopping inflation within 0L, while creating a mechanism for funding ongoing validator incentives in the absence of issuance. There are three parts to the proposal: (1\) stop issuance; (2\) rebase the token; and (3\) create and fund an Infrastructure Escrow community wallet to provide validator rewards. The proposal asks for a single vote on all three parts; the three parts are interconnected and dependent. - - - - -**Voting Result:** This proposal passed by the largest margin (\+134\) and also showed the largest commitment of voting power (1,036 credits). Looking at the raw numbers in the voting, this proposal received the largest total number of positive votes and the highest number of voters. - - - - -**Comments**: Clearly, this was the topic of greatest concern to the community. The large positive vote was a bit of a surprise given the complexity of this proposal (3 parts) and the significant impact it would have on the systemโ€™s tokenomics.ย  - - - - -### [Proposal 2210\-02 Proof of Fee](http://openlibra.blog/2022/10/11/proposal-2210-2-proof-of-fee/) - - - - -**Synopsis**: Proof of Fee could be used to partially replace 0L's current security model by adding new economic guarantees. - - - - -**Voting Result**: Passed by a reasonable margin (\+63\) and received the second largest amount of voting power (579\). A look at the raw data shows this proposal had the third\-largest number of voters and received the largest number of negative votes. - - - - -**Comments**: This was a highly technical question that is primarily of interest to validators (existing or potential). The high levels of commitment, combined with the median result in the voting margin, shows that there were strong opposing opinions about this. The large number of negative votes also shows this to be one of the most divisive proposed changes to the networkโ€™s technical architecture. - - - - -### [Proposal 2210\-03 Musical Chairs](http://openlibra.blog/2022/10/11/proposal-2210-3-musical-chairs/) - - - - -**Synopsis**: Change the way the validator selection set is chosen so that performance and cost can be optimized in a competitive way.. - - - - -**Voting Result**: Passed with the smallest margin of any of the full proposals (\+61\) and showed a moderate amount of commitment in terms of voting power (191\). A look at the raw data shows this proposal had the second\-highest number of negative votes. - - - - -**Comments**: Like proposal 1022\-02, this proposal presents a highly technical question that is primarily of interest to validators (existing or potential). This passed, but by the smallest margin of the entire set of proposal, and with a significant number of negative votes, indicating that this proposal is likely the most controversial of the entire set. - - - - -### [Proposal 2210\-04 Repurpose Carpe](http://openlibra.blog/2022/10/11/proposal-2210-4-repurpose-carpe/) - - - - -**Synopsis**: Move the Carpe app away from building towers and use it for something else, maybe as an oracle for the network. - - - - -**Voting Result**: Passed by with a reasonable margin (\+74\), but showed the second lowest amount of commitment in terms of voting power of any of the proposals (306\). A look at the raw data shows this proposal had the second highest number of voters. - - - - -**Comments**: A large number of voters with a low expenditure of voting power would indicate that while people had opinions on this proposal, they were not strongly held.ย  - - - - -### [Proposal 2210\-05 Revenue Binding Primitives](http://openlibra.blog/2022/10/11/proposal-2210-5-revenue-binding-primitives/) - - - - -**Synopsis**: Tells the engineering team to make 0L protocol primitives that support a variety of payment functions that will be needed for future app development their top priority.ย  - - - - -**Voting Result**: Passed by the second\-largest margin (\+85\), but showed a relatively low amount of commitment in terms of voting power (335\). A look at the raw data shows that there were no votes against this proposal, one of only two to pass without opposition. - - - - -**Comments**: A non\-controversial proposal that advocates for building tooling, this proposal passed easily. - - - - -### [Proposal 2210\-06 Faucets for Workers](http://openlibra.blog/2022/10/11/proposal-2210-6-faucets-for-workers/) - - - - -**Synopsis**: Create faucet tooling for Community Wallets and others to create automated rewards. - - - - -**Voting Result**: Passed with the smallest margin of any of the full proposals (\+36\) and showed the lowest commitment of voting power of any of the proposals (191\). A look at the raw data shows this proposal had no negative votes, one of only two to pass without opposition. - - - - -**Comments**: This proposal was non\-controversial, but generated low engagement, suggesting that it is generally supported but not necessarily a top priority for the community. - - - - -### [Proposal 2210\-07 Donor\-Directed Community Wallets](http://openlibra.blog/2022/10/11/proposal-2210-7-donor-directed-community-wallets/) - - - - -**Synopsis**: Create better oversight of community wallets such that they are actually donor\-directed, and have purpose\-built multisignature features. - - - - -**Voting Result**: Passed with the third highest margin of any of the full proposals (\+76\) and showed a moderate amount of commitment in terms of voting power (354\). A look at the raw data shows this proposal had only one negative vote. - - - - -**Comments**: The result here aligns with what weโ€™ve been hearing in community conversations, namely, that community wallets, as designed, are underperforming and need to better support more complex governance. - - - - -### [Proposal 2210\-08 Infrastructure Escrow Fund](http://openlibra.blog/2022/10/11/proposal-2210-8-infrastructure-escrow-funding/) - - - - -**Synopsis**: This proposal asked voters to indicate how they wished the cost of the Infrastructure Escrow Fund to be allocated among the existing wallet holders. Voters could vote for, or against, charging each of four categories: Validators, Community Wallets, Carpe Miners, or Basic Wallet Holders.ย  - - - - -**Voting Result**:ย  - - - - -2. Validators: \+67 (487 commitments) - -6. Community Wallets: \+58 (446 commitments) - -10. Carpe Miners: \+1 (147 commitments) - -14. Basic Wallet Holders: 0 (156 commitments) - - - - -**Comments**: There is a clear and strong preference for diluting the Validators and Community Wallets. The results of this vote will be used to create the formula used for diluting all the wallet holders, a process needed to implement the Infrastructure Escrow Fund (as per Proposal 1022\-1 Final Supply). - - - - -## Where do we go from here? - - - - -It is important to note that all the proposals presented in this process were signaling proposals, that is, they were created to help define consensus and formulate direction and strategy for the network. None of the proposals resulted in immediate changes to the network, either online or offline. Rather, these proposals form the basis for taking further action to accomplish the strategic goals defined by this vote. Given that, it is hard to categorize any of these proposals as winners or losers; rather, they all served as indicators of future direction and required significant additional effort from the community. - - - - -Stepping back a moment and looking at the sum of the proposals on the slate: - - - - -* Despite some controversy displayed in the discussions around the Final Supply proposal (Proposal 2210\-01\), the vote revealed a clear mandate to move forward. The proposal was sweeping in its proposed changes and included (1\) stopping issuance, (2\) rebasing the token, and (3\) creating the Infrastructure Escrow Fund. Implementing these changes would represent a significant change in direction for the tokenomics of the project. This is our strongest indication of direction from the community and therefore deserves to be prioritized. - -* Given the results of the votes on the four parts of the Infrastructure Escrow Fund (Proposal 1022\-08\), the re\-basing should result almost exclusively in the dilution of Validators and Community Wallets, with only a token contribution coming from the Carpe Miners. Basic Wallet holders (i.e., workers, other token holders) would not be impacted. - -* Two of the proposals aimed squarely at our validator operations, Proof of Fee (1022\-02\) and Musical Chairs (1022\-03\), gave us more ambiguous results and better reflected the divided discussions that occurred in the run\-up to the vote. Though both of these changes passed, it seems clear that there should be further discussion and perhaps refinement of these proposals to achieve better consensus. - -* The question of what to do with the Carpe app in light of the changes proposed above also remains open. While the proposal to repurpose Carpe (1022\-04\) passed, it showed a lack of commitment, which may reflect the fact that while the community recognizes that Carpe has value and that we should do something with it, no one is exactly sure what the best course of action is for the future of the app. - -* The remaining three proposals (Revenue Binding Primitives, Faucets for Workers, and Donor Directed Community Wallets), were all non\-controversial, and the results were consistent with that. The low levels of commitment on proposals 1022\-05 and 1022\-06 would indicate that these matters, while non\-controversial, are also not priorities. In contrast, the higher levels of engagement on 1022\-07 (Donor\-Directed Community Wallets), would indicate that this proposal should be moved forward more quickly. - - - - -At the end of all this, the answer to the question โ€œwhere do we go from here?โ€ depends on whether the individual members of our community can move forward with collaborative action. The successful completion of this community strategy development process, while meaningful, is all for naught if the community does not step up and commit the resources needed to operationalize the strategy. diff --git a/docs_old/archive/proposals/proposal_2210_1_final_supply.md b/docs_old/archive/proposals/proposal_2210_1_final_supply.md deleted file mode 100644 index 781275af..00000000 --- a/docs_old/archive/proposals/proposal_2210_1_final_supply.md +++ /dev/null @@ -1,132 +0,0 @@ - -###### Proposal Type: **Signalling** - - - - -###### Champion: **ricoflan** - - - - -###### Date: **11 October 2022** - - - - -###### State: **Draft / Work In Progress** - - - - -### **Context** - - - - -This proposal relates to the biggest opportunity 0L has. With this proposal, the community is in a unique position to create a balanced, equitable approach to sustainability in which all participants are of a single class: All participants are workers.ย  - - - - -The current 0L token issuance schema is dramatically diluting workers while enriching the validators via issuance of new tokens each epoch (i.e., inflation). Anyone who has earned bounties, or engineering funds, have had their value reduced significantly by inflation across the last 6 months. This needs to change. - - - - -The challenge to stopping inflation is how to preserve incentives for validators without ongoing issuance. This proposal seeks to stop inflation by ending issuance while providing a means to fund validator incentives for the medium to long term. - - - - -### **Synopsis** - - - - -This proposal seeks to scaffold a permanently deflationary coin. There are three parts to the proposal: (1\) stop issuance; (2\) rebase the token; (3\) create and fund an Infrastructure Escrow community wallet to provide validator rewards. The proposal asks for a single vote on all three parts; the three parts are interconnected and dependent. - - - - -1. Stop Issuance: The first part of this proposal is the simplest: Stop issuance of new tokens. -2. Rebase the Token: In order to fund the Infrastructure Escrow wallet (see, \#3 below), there must be some form of dilution. The simplest, and most regulatory compliant way is to rebase the existing token by splitting each coin by approximately 5 (final calculations TBD) such that the total final supply is 10B coins. This in effect expands significantly the supply in a one time action; all account holders will have a higher account balance after the rebasing. (Note that this proposal only establishes a mandate to rebase; the exact methodology will be the subject of a separate, subsequent governance action if this passes.) -3. Create and Fund the Infrastructure Escrow community wallet: A new community wallet will be created to serve as an escrow for future validator rewards. This wallet will be funded from the tokens created by the rebasing of the token (see \#2, above).ย  (Note that this proposal only establishes a mandate to create and fund; the exact methodology will be the subject of a separate, subsequent governance action if this passes.) - - - - -All three actions will be included in the Version 6 upgrade to the Protocol. - - - - -### **Impact of Voting YES on this Proposal** - - - - -A vote of YES on this proposal will signal to the Engineering Team and the Validator set the communityโ€™s desire to enact the following changes in the Version 6 Protocol Upgrade: - - - - -1. Stop issuance of tokens -2. Rebase the token using a formula to be determined in subsequent governance action -3. Create a new community wallet named Infrastructure Escrow -4. Transfer into that wallet a number of tokens to be determined by subsequent governance action -5. Note the impact of the passage of this proposal on token holders in multi-fold: - 1. There will be more tokens in the system. - 2. All wallets will show higher balances. - 3. A formula will be devised to allocate a portion of those tokens from all wallets to the new Infrastructure Escrow. That formula will need to be determined in subsequent governance actions. - - - - -### **Impact of Voting NO on this Proposal** - - - - -A vote of NO on this proposal will reject all parts of this proposal and issuance-driven inflation will remain in effect as it is currently. - - - - -* The author(s) believe that a clear path to a mission-aligned revision of our tokenomics is essential for the community, so in the event that you choose to vote against this proposal, we welcome you to engage with the community to collaborate on the creation of a policy that is acceptable to the community at large. - - - - -#### **Special Notes:** - - - - -* Note that this is a signalling proposal and therefore does not directly impact the chain; subsequent action is required to implement these changes. -* The outcomes of this proposal can be modified by the community via a subsequent proposal and vote - - - - -#### **Reference Materials:** - - - - -* See also, Proposal 2210-8, Infrastructure Escrow Funding - - - - - -Notes on Process - - - - -* This document is a Draft / Work in Progress. It will change until marked as FINAL. **The closing date for revisions is 15 October**. -* Publication here is an invitation for community collaboration and co-creation. -* To engage on this content, visit the **\#governance-proposals** channel on the 0L Discord (link at bottom right) -* Once this Proposal is finalized, it will be the subject of Voting on the Radical X Change platform. If you do not yet have credentials, visit the **\#rxc-voice-discussion** channel on the 0L Discord and make a request to join. -* **Voting opens 17 Oct and closes 22 Oct** diff --git a/docs_old/archive/proposals/proposal_2210_2_proof_of_fee.md b/docs_old/archive/proposals/proposal_2210_2_proof_of_fee.md deleted file mode 100644 index ea1d25a1..00000000 --- a/docs_old/archive/proposals/proposal_2210_2_proof_of_fee.md +++ /dev/null @@ -1,171 +0,0 @@ - -###### Proposal Type: Signalling - - - - -###### Champion: 0o-de-lally - - - - -###### Date: 13 October 2022 - - - - -###### State: Draft / Work in Progress - - - - -### **Context** - - - - -As an alternative to the (near-universally deployed) Delegated Proof of Stake we propose a sybil resistance technique designed natively for the benefits and tradeoffs of PBFT consensus, we call that system Proof-of-Fee (PoF). This proposal seeks to replace the Delay Towers mechanism currently in place with Proof-of-Fee.ย  - - - - -Profits to blockchains are slim to non-existent. Low consensus costs are foundational for any chain that wishes to provide consumer surplus and profit to coin-holders; where excess winnings of the chain can be distributed to *all* account holders, that is, without preference to an investor class of "stakers". In PoF, the cost of consensus is lowered maximally to the *operator opportunity cost*, and such that the social cost (of dilution through issuance) is minimized. - - - - -Validator seats are auctioned at each epoch, such that the validators private valuation of rewards, MEV, breakage, and governance is revealed. PoF coins have superior ergonomics. Every actor has a very simple instruction; no staking, no yield games, no slashing. Holding the coin is the dominant strategy. - - - - -### **Synopsis** - - - - -Proof of Fee partially replaces the current security model of 0L, by introducing novel economic guarantees layered with the validator admission through Vouches and Jail reputation. - - - - -The proposal has two parts: - - - - -1. Define a new validator incentives mechanism, and -2. Replace Delay Towers with Proof of Fee. - - - - -Hereโ€™s how each part works: - - - - -**Part 1: Define a New Validator Incentives Structure (i.e., determining how much is paid)** - - - - -* 0L will shift from the algorithmic calculation of validator incentives that we presently employ, to a fee that is a percentage of the total supply. The percentage is stable across epochs. -* Each successful validator will receive an equal amount as other validators in incentives each epoch. -* The amount of the fee is a parameter subject to governance action (and hence is adjustable on vote by the community). -* The amount should be minimal (e.g., single digit percentages of the total supply per year) yet designed to provide adequate incentives for validators to secure and maintain a reliable network. -* Incentives will be paid from the Infrastructure Escrow community wallet (see, Proposal 2210-1\) - - - - -**Part 2: Implement Proof of Feeย  (i.e., determining who gets to be paid)** - - - - -Proof of Fee creates a competitive auction mechanism to pick who gets to participate in the validator set each epoch. Hereโ€™s an overview of how it works, a thorough paper is forthcoming: - - - - -* At the beginning of each epoch, all validators who wish to participate in the epoch will place a bid (an Entry Fee). -* There is a limit to the number of validators in an epoch, the ones with the highest bids will enter the epoch. -* Validator consensus power is determined by the entry fee. -* Each validator bids their highest entry fee, with the expectation of receiving a flat fee at the end of a successful epoch. -* The initial proposed auction type is a Generalized Second Price Auction (a variation of the Nth Price Auction), which means the validator doesn't pay their maximum bid, but the bid of the next person immediately below them. (note: Future variations on this auction are possible and should be explored) -* Bids in excess of the pre-defined validator incentive for that epoch (i.e., a negative bid) will be permitted, within limits (e.g. 110% of the reward). The limit is a parameter subject to governance action (and hence is adjustable on vote by the community) -* At completion of the epoch, the pre-defined incentive amount will be paid to all validators that successfully completed the epoch. (The entry fee was already be paid thus, the net reward to a validator will be: Gross Incentive - Entry Fee \= Net Amount Received by Each Validator) - - - - -All actions will be included in the Version 6 upgrade to the Protocol. - - - - -### **Impact of Voting YES on this Proposal** - - - - -A vote of YES on this proposal will signal to the Engineering Team and the Validator set the communityโ€™s desire to enact the following changes in the Version 6 Protocol Upgrade: - - - - -1. Create new epoch reward amount, with parameter for governance, -2. If Final Supply proposal passes, then the validator reward will be extracted from the Infrastructure Escrow community wallet (no new coins will be minted). -3. Disable Delay Towers for Validator Sybil Resistance Purposes. -4. Implement Proof of Fee with all necessary dependencies - - - - -### **Impact of Voting NO on this Proposal** - - - - -A vote of NO on this proposal will reject all parts of this proposal and retain the Delay Towers mechanism that is currently in place. - - - - -* The author(s) believe that revision of our current approach to consensus is essential for the community, so in the event that you choose to vote against this proposal, we welcome you to engage with the community to collaborate on the creation of a policy that is acceptable to the community at large. - - - - -### **Special Notes:** - - - - -* Note that this is a signalling proposal and therefore does not directly impact the chain; subsequent action is required to implement these changes. -* The outcomes of this proposal can be modified by the community via a subsequent proposal and vote - - - - -### **Reference Materials:** - - - - -* See also, Proposal 2210-1, Final Supply, for an explanation of the Infrastructure Escrow Community Wallet - - - - -#### **Notes on Process** - - - - -* This document is a Draft / Work in Progress. It will change until marked as FINAL. **The closing date for revisions is 15 October.** -* Publication here is an invitation for community collaboration and co-creation. -* To engage on this content, visit the **\#governance-proposals** channel on the 0L Discord (link at bottom right) -* Once this Proposal is finalized, it will be the subject of Voting on the Radical X Change platform. If you do not yet have credentials, visit the **\#rxc-voice-discussion** channel on the 0L Discord and make a request to join. -* **Voting opens 17 Oct and closes 22 Oct** diff --git a/docs_old/archive/proposals/proposal_2210_3_musical_chairs.md b/docs_old/archive/proposals/proposal_2210_3_musical_chairs.md deleted file mode 100644 index 71c77bb9..00000000 --- a/docs_old/archive/proposals/proposal_2210_3_musical_chairs.md +++ /dev/null @@ -1,165 +0,0 @@ - -###### Proposal Type: Signalling - - - - -###### Champion: TBD - - - - -###### Date: 10 October 2022 - - - - -###### Status: Draft / Work in Progress - - - - -### **Context** - - - - -0L hasn't attempted to use Proof of Stake to filter malicious actors. Historically, we have had multiple layers of sybil resistance to prevent a malicious actor from amplifying attacks by multiplying the nodes they have access to. Vouches, social dynamics, and Delay Towers all work collectively to provide some resistance to bad actors. The mechanisms implemented to date have been sufficient for bootstrapping but are likely to prove inadequate at steady state. - - - - -The current design of 0L makes it such that validators compete less among themselves as the count of nodes expands. For example, at 60 seats, the next epoch will have 10 slots open (the network always makes โ…™ the number of seats available). This means the competition is lower as the network progressively increases, which may be counter to the needs of the network. Meaning: when the validator set is large, the performance in TPS goes down, and better higher-quality validators are needed (not more seats with validators of unknown quality). Also when the set is large, it may also intersect with be that demand for the network services being are high. In those cases we want more, or at least the same, amount of competition. - - - - -The validator set needs to be optimized for both performance and reliablility. The current selection process utilized by 0L optimizes for neither of those attributes, being based instead, on purely numerical conditions. A revised approach could advance both performance and reliability. - - - - -It is expected that implementing the process described in this proposal will result in: - - - - -1. Greater competition -2. Higher performance in vulnerable conditions -3. Lower costs to the network -4. Competition at any size - - - - -We expect validator selection to be more competitive than the current design. By reducing the โ…™ expansion criteria to a fixed 1 seat, only when perfect performance is achieved by the collective, then we expect that there will be greater competition for the validator set. - - - - -Performant validators are not guaranteed a position, except when the network is vulnerable. In the case of subsequent reductions in the validator set because of extrinsic factors, the validator set progressively reduces to the most performant nodes, before becoming competitive again. - - - - -What Musical Chairs modifies, is that in a shrinking event, the validators which performed are guaranteed a seat. But as soon as a new seat opens up, then all validators must again compete on price (Delay Towers or Proof of Fee proposal) - - - - -### **Synopsis** - - - - -With musical chairs, the validator set has no maximum limit. Whatever it's size (M) it is currently at its limit. Validators compete for seats through normal mechanism (Tower height) or a different cost (Proof of Fee), when the validator set is performant. - - - - -Whenever the validator set has perfect performance by all nodes, the set can increase by 1 seat (M \+ 1\). No validators are guaranteed a seat when the seat count is stable or growing. They compete on the lowest cost of service provided (cost of consensus). In the event of a validator set where one node did not perform (M - 1\), then the next epoch will include all the performant validators LESS the one non-performing (the new size is M - 1\). - - - - -There key attributes of Musical Chairs are: - - - - -1. The validator set has no fixed upper bound of validator seats (i.e., no longer fixed at 100\). -2. The validator set only expands if every member of the validator set performed above threshold - and then it only increases by 1 seat. -3. If any validator(s) did not perform, the validator set is reduced by the size of the non-performing validator(s) - and the expansion begins again. -4. In a shrunk validator set, all of the performant validators are allowed to remain, though if the validator set resumes increasing, they must compete on cost. - - - - -All actions will be included in the Version 6 upgrade to the Protocol. - - - - -A vote of YES on this proposal will signal to the Engineering Team and the Validator set the communityโ€™s desire to enact the following changes in the Version 6 Protocol Upgrade: - - - - -### **Impact of Voting YES on this Proposal** - - - - -1. Create the Musical Chairs functionality and all necessary dependencies -2. Disable the present validator selection set methodology -3. Implement Musical Chairs - - - - -### **Impact of Voting NO on this Proposal** - - - - -A vote of NO on this proposal will reject all parts of this proposal and retain the validator set sizing mechanism that is currently in place. - - - - -* The author(s) believe that revision of our current approach to validator set sizing is essential for the community, so in the event that you choose to vote against this proposal, we welcome you to engage with the community to collaborate on the creation of a policy that is acceptable to the community at large. - - - - -### **Special Notes:** - - - - -* Note that this is a signalling proposal and therefore does not directly impact the chain; subsequent action is required to implement these changes. -* The outcomes of this proposal can be modified by the community via a subsequent proposal and vote - - - - -### **Reference Materials:** - - - - -* See also, Proposal 2210-2, Final Supply, for an explanation of Proof of Fee, which is closely related to this proposal - - - - -#### **Notes on Process** - - - - -* This document is a Draft / Work in Progress. It will change until marked as FINAL. The closing date for revisions is 15 October. -* Publication here is an invitation for community collaboration and co-creation. -* To engage on this content, visit the **\#governance-proposals** channel on the 0L Discord (link at bottom right) -* Once this Proposal is finalized, it will be the subject of Voting on the Radical X Change platform. If you do not yet have credentials, visit the **\#rxc-voice-discussion** channel on the 0L Discord and make a request to join. -* **Voting opens 17 Oct and closes 22 Oct** diff --git a/docs_old/archive/proposals/proposal_2210_4_repurpose_carpe.md b/docs_old/archive/proposals/proposal_2210_4_repurpose_carpe.md deleted file mode 100644 index 4fd23ef8..00000000 --- a/docs_old/archive/proposals/proposal_2210_4_repurpose_carpe.md +++ /dev/null @@ -1,96 +0,0 @@ - -###### Proposal Type: Signalling - - - - -###### Champion: TBD - - - - -###### Date: 11 October 2022 - - - - -###### State: Draft / Work in Progress - - - - -### **Context** - - - - -If Proposal 2210-2 Proof of Fee passes, the need for Towers will be eliminated and Carpe users will have nothing to do. This proposal advocates for one approach (an oracle service) to creating utility for Carpe. Additionally, 0L is seeking to have more revenue opportunities for the chain and expanded functionality. Oracles are ways of getting off-chain data onto the chain, e.g. getting the price of a coin from a website. The design does not foreclose other future uses for Carpe. - - - - -### **Synopsis** - - - - -This proposal advocates that we take advantage of the Carpe installed base and repurpose Carpe into an Oracle Protocol, which in the future would be another source of revenue. Common oracle use cases are for the scraping of pricing data and exposing it on chain for apps to consume the data. Other similar uses are also possible. As such, oracles are a foundational piece of blockchain architecture that enables other services to function onchain in 0L. - - - - -* While the nature and pricing of the service will require subsequent governance action, a simple revenue model could work like this: The Oracle service will charge fee for its data stream that revenue should be designed to cover the Carpe costs. -* When revenue surpasses Carpe costs, then the remainder should be burned (i.e. redistributed to all accounts). -* Initially, as revenues ramp up, a subsidy will be needed to keep Carpe users mining until the Oracle product is complete. - - - - -### **Impact of Voting YES on this Proposal** - - - - -1. Tower mining, and the Identity Subsidy, by Carpe will NOT stop when towers are discontinued with Proof of Fee. It will continue until an Oracle subsidy or Oracle product can be introduced. -2. The Engineering team will design and build an oracle function for Carpe Miners -3. The oracle upgrade will be distributed for on-chain policy upgrades (AKA Stdlib), and upgrades to Carpe. - - - - -### **Impact of Voting NO on this Proposal** - - - - -ย If this proposal is defeated, Carpe mining will have no reward, and Carpe will continue only as a wallet. - - - - -* If Delay Towers are abandoned (as per Proposal 2210-2 Proof of Fee, or other governance action), then Carpe will cease to function. -* Note that if this proposal is defeated, there will remain a need to explore future expansion of Carpe functionality, or the sunsetting of the Carpe app. The author encourages those who vote No on this proposal to work with the community to find a means to address these challenges. - - - - -### **Reference Materials** - - - - -* See Proposal 2210-2, Proof of Fee, for an explanation of Proof of Fee and how that would replace Delay Towers. - - - - -#### **Notes on Process** - - - - -* This document is a Draft / Work in Progress. It will change until marked as FINAL. The closing date for revisions is 15 October. -* Publication here is an invitation for community collaboration and co-creation. -* To engage on this content, visit the **\#governance-proposals** channel on the 0L Discord (link at bottom right) -* Once this Proposal is finalized, it will be the subject of Voting on the Radical X Change platform. If you do not yet have credentials, visit the **\#rxc-voice-discussion** channel on the 0L Discord and make a request to join. -* **Voting opens 17 Oct and closes 22 Oct** diff --git a/docs_old/archive/proposals/proposal_2210_5_revenue_binding_primitives.md b/docs_old/archive/proposals/proposal_2210_5_revenue_binding_primitives.md deleted file mode 100644 index 58374e41..00000000 --- a/docs_old/archive/proposals/proposal_2210_5_revenue_binding_primitives.md +++ /dev/null @@ -1,94 +0,0 @@ - -###### Proposal Type: Signalling - - - - -###### Champion: TBD - - - - -###### Date: 11 October 2022 - - - - -###### State: Draft/Work in Progress - - - - -### **Context** - - - - -The community has signaled the importance of profitable unit economics. Experimentation is needed in order to create revenue streams from a) new protocol products, b) third party applications and c) off-chain businesses. Currently in the 0L tech stack, there are few functions, or bindings for that experimentation take place. This proposal advocates for the network to create this foundational tooling. - - - - -### **Synopsis** - - - - -Develop new protocol services. Third party apps, and offline protocols need an easy way to charge fees in 0L coins. Priorities: - - - - -* Helpers in DiemAccount.move to facilitate future products - + Bridge - + Name service - + Indexing Service - + Exchange -* Applications and Off-chain Scaffolds for Revenue - + Create App revenue bindings - + Simple transaction capabilities, tracking, and bindings should be provided. - - - - -### **Impact of Voting YES on this Proposal** - - - - -1. The 0L standard library will be extended so that developers can easily charge fees in 0L coins, which will help generate revenue to the chain. -2. Engineers will be funded to work on developing a spec and delivering the code. - - - - -### **Impact of Voting NO on this Proposal** - - - - -1. This will not be worked on at the moment, and third party developers need to issue their own coins for apps. - - - - -#### **Reference Materials** - - - - -* n/a - - - - -**Notes on Process** - - - - -* This document is a Draft / Work in Progress. It will change until marked as FINAL. The closing date for revisions is 15 October. -* Publication here is an invitation for community collaboration and co-creation. -* To engage on this content, visit the **\#governance-proposals** channel on the 0L Discord (link at bottom right) -* Once this Proposal is finalized, it will be the subject of Voting on the Radical X Change platform. If you do not yet have credentials, visit the **\#rxc-voice-discussion** channel on the 0L Discord and make a request to join. -* **Voting opens 17 Oct and closes 22 Oct** diff --git a/docs_old/archive/proposals/proposal_2210_6_faucets_for_workers.md b/docs_old/archive/proposals/proposal_2210_6_faucets_for_workers.md deleted file mode 100644 index d8068f9c..00000000 --- a/docs_old/archive/proposals/proposal_2210_6_faucets_for_workers.md +++ /dev/null @@ -1,107 +0,0 @@ - -###### Proposal Type: Signalling - - - - -###### Champion: TBD - - - - -###### Date: 11 October 2022 - - - - -###### State: Draft/Work in Progress - - - - -### **Context** - - - - -The proposals Proof of Fee (2210-2\) and Final Supply (2210-1\) are targeted at adjusting rewards from validators, with the goal of incentivizing the best performing validators. In line with the vision of creating an entrepreneurial cooperative, the 0L Network should also have a low-friction way for workers to organize themselves and receive streams of payments, in the absence of algorithmic rewards. This proposal takes a first step in that direction. - - - - -### **Synopsis** - - - - -This proposal advocates for the Engineering team to prioritize the development of functionality that will enable a simple mechanism for routing payments to working via the creation of a Move 0L framework (AKA stdlib) tools for entities to create and fund faucets. Features would include: - - - - -1. Anyone can start a Faucet -2. Faucets can have one or more administrators -3. The faucet can receive donations (from Community Wallets or users). -4. A user can claim a self-service payment from a faucet - - - - -The self-service aspects of the faucets will be gated, as follows: - - - - -* The more users claiming the longer it takes for payment to process. -* The payment happens automatically unless an administrator intervenes. -* Certain faucets may require credentials (an NFT) before one can join. - - - - -A leading use case for this would be the Hustle Karma DAO, which can reduce overhead and speed payments by allowing users to self-paying for their work. - - - - -### **Impact of Voting YES on this Proposal** - - - - -1. Faucets would become an 0L stdlib feature which Community Wallets and others could use. -2. An engineering group would be funded to develop the Faucets tooling. The code would be merged to Move Stdlib on completion. - - - - -### **Impact of Voting NO on this Proposal** - - - - -* No Engineering effort in this area would be undertaken absent additional governance action. - - - - -#### **Reference Materials** - - - - -* n/a - - - - -**Notes on Process** - - - - -* This document is a Draft / Work in Progress. It will change until marked as FINAL. The closing date for revisions is 15 October. -* Publication here is an invitation for community collaboration and co-creation. -* To engage on this content, visit the **\#governance-proposals** channel on the 0L Discord (link at bottom right) -* Once this Proposal is finalized, it will be the subject of Voting on the Radical X Change platform. If you do not yet have credentials, visit the **\#rxc-voice-discussion** channel on the 0L Discord and make a request to join. -* **Voting opens 17 Oct and closes 22 Oct** diff --git a/docs_old/archive/proposals/proposal_2210_7_donor_directed_community_wallets.md b/docs_old/archive/proposals/proposal_2210_7_donor_directed_community_wallets.md deleted file mode 100644 index 636efb90..00000000 --- a/docs_old/archive/proposals/proposal_2210_7_donor_directed_community_wallets.md +++ /dev/null @@ -1,175 +0,0 @@ - -###### Proposal Type: Signalling - - - - -###### Champion: TBD - - - - -###### Date: 12 October 2022 - - - - -###### State: Draft / Work in Progress - - - - -### **Context** - - - - -This proposal is focused on improving alignment of community wallets through governance levers. - - - - -As a reminder, all community wallets are owned by a real world entity, not by the chain. As such those real world entities have real world liabilities if they misuse the funds donated to them. This off chain governance layer is expensive and slow to catch problems. Smart contract capabilities can help create proper governance. - - - - -Current Challenges: - - - - -* Community wallets hold a great amount of coins, but most are inactive. -* There is a perception that community wallets are for enrichment of participants (not donor directed funds for growth). -* Stopping Community wallets from misbehaving is hard. - - - - -There's nothing the protocol can do to take money away from community wallets, or to censure certain wallets. Forking and removing certain coins can be done by the validator set, though this is politically impossible. What can be done is to correct some of the governance issues in the wallets; this proposal seeks to do that. - - - - -### **Synopsis** - - - - -There are five parts to this proposal to enhance Community Wallets.ย  - - - - -**1\.****Implement Donor Direction** - - - - -Typically within our community, the Community Wallets have been idealized and spoken about as being "donor directed". However we had no proper tracking on-chain of the donations to actually realize this vision. As an intermediary step, we said the validators would be the authorities over veto and freezing of these wallets. This was fine when there was a large overlap of donors and active validators, but today this has already diverged significantly. - - - - -We already have the donation tracking (the Receipts module) and with the v6 fork we can do two things to improve Community Wallet governance. - - - - -* Confirm that the values are correct per donor account (and sum to the value of donations), and -* Update the voting mechanism to use the Receipts module, thereby enabling the donors to have oversight over the expenditures rather than depending on action by the validator set. - - - - -**2\.****Inclusion in the Burn Index** - - - - -Additionally, with the v6 fork we can also add Community Wallets to the Burn Index, which will give every account in 0L the option to have their costs (burns) be recycled to an index of community wallets.ย  - - - - -**3\.****Optimization of Voting Thresholds** - - - - -Since participation is low in community wallets and the monitoring tools are lacking, the voting thresholds for rejecting and ultimately freezing wallets should be lowered. - - - - -* A community wallet transaction should be rejected if 1/6th of the donors disapprove with a veto. Three consecutive Vetos would mean freezing of the account, no changes there. -* There was no way to directly freeze a wallet. A wallet can also be frozen if 1/6th of the donors choose to do so. And can be unfrozen if 2/6th of the donors choose to do so. - - - - -**4\.** **Define A Community Wallet as a Donor Directed Wallet with a Multisig** - - - - -* The new Policy would be: For a community wallet to be included in the Burn Index, and for unrestricted transactions from Transfer and Autopay functionality, the wallet will have to have a minimum of 3 of 4 multisig. The multisig will be implemented in the Donor Directed contract (as opposed to by off-chain signing wallets). -* Multisig signers for Community Wallets must have a threshold number of addresses that are unrelated (from different Ancestry in the permission trees). - - - - -**5**. **Create tools for monitoring and reacting to community wallets** - - - - -* Build monitoring and reporting into 0LExplorer.io -* Create interactive reports on Carpe - - - - -### **Impact of Voting YES on this Proposal** - - - - -1. Community Wallet policies will be changed to correct their behavior such that they are actually donor directed, and that they use multisigs for transaction approval. -2. Developers would be funded to create the code in line with the 5 changes outlined, above. -3. Carpe and 0L Explorer developers should be funded to create monitoring tools. - - - - -### **Impact of Voting NO on this Proposal** - - - - -1. Community Wallets will continue to have low oversight by the people and entities that funded them. -2. It will be difficult to catch one bad actor who abuses the Burn Match Index mechanism, since it doesn't require a diverse multisig, and there are no monitoring tools. - - - - -#### **Reference Materials:** - - - - -* n/a - - - - -**Notes on Process** - - - - -* This document is a Draft / Work in Progress. It will change until marked as FINAL. **The closing date for revisions is 15 October.** -* Publication here is an invitation for community collaboration and co-creation. -* To engage on this content, visit the **\#governance-proposals** channel on the 0L Discord (link at bottom right) -* Once this Proposal is finalized, it will be the subject of Voting on the Radical X Change platform. If you do not yet have credentials, visit the **\#rxc-voice-discussion** channel on the 0L Discord and make a request to join. -* **Voting opens 17 Oct and closes 22 Oct** diff --git a/docs_old/archive/proposals/proposal_2210_8_infrastructure_escrow_funding.md b/docs_old/archive/proposals/proposal_2210_8_infrastructure_escrow_funding.md deleted file mode 100644 index 4604b936..00000000 --- a/docs_old/archive/proposals/proposal_2210_8_infrastructure_escrow_funding.md +++ /dev/null @@ -1,119 +0,0 @@ - -###### Proposal Type: Signalling - - - - -###### Champion: 0o-de-lally - - - - -###### Date: 12 October 2022 - - - - -###### State: Draft / Work in Progress - - - - -### **Context** - - - - -If the Final Supply proposal (2210-1\) passes, an Infrastructure Escrow Community Wallet will be created to provide future validator rewards; this is a replacement for the daily minting of coins. The need for validator incentives will remain after minting of new coins stops, and this fund is designed to fill that gap into the medium term future (5-10 years).ย  - - - - -Note that the re-basing contemplated by the Final Supply proposal means that the total supply will increase by a multiple. That multiple can be applied equally to all wallet types or distributed among the wallet holders in a variety of unequal fashions. The funds for the Infrastructure Escrow Community Wallet have to come from somewhere. So, as the supply is increased by the re-basing, a portion of tokens need to be carved off and put into a Community Wallet to pay for future incentives. It is inevitable that someone has to be diluted. This proposal asks voters to signal how they want that burden to be distributed. - - - - -### **Synopsis** - - - - -The escrow fund should cover between 5 and 10 years of network infrastructure subsidies. To achieve that, wallets will have to be diluted. This proposal asks you how you prefer that dilution to occur; it asks you who do you want to see diluted. The options are:\\ - - - - -1. Carpe Miners -2. Workers -3. Validators -4. Community Wallets - - - - -Based on the expression of preference by the voters, a formula will be created.ย  - - - - -Remember, this is a quadratic voting process so you can express strong preferences here if you so desire. Quadratic Voting shows conviction voting on each of these variants, and based on that we can estimate how much each party should pay and put that forward in a subsequent governance action.ย  - - - - -(By way of example: If the community votes equally strongly to dilute all, then all accounts should be diluted. In contrast, if two of the categories of wallets stand out equally then those wallets would have the same dilution (while the other two none). And variations on this.) - - - - -### **Impact of Voting YES on this Proposal** - - - - -1. Voting Yes on any of the variants increases the share that the group in question will contribute to the infrastructure escrow. Voting with greater conviction will increase the share. - - - - -### **Impact of Voting NO on this Proposal** - - - - -Voting No on any variant, reduces the proportion that the group will contribute to the escrow fund. Voting NO with greater conviction reduces the share. - - - - -### **Impact of Abstaining on this Proposal** - - - - -* If you do not have conviction on these items, (you use your Quadratic Voting credits elsewhere) the proportions will be set by other voters. - - - - -#### **Reference Materials** - - - - -* See also, [Proposal 2210-1, Final Supply](http://openlibra.blog/2022/10/11/proposal-2210-1-final-supply/) - - - - -**Notes on Process** - - - - -* This document is a Draft / Work in Progress. It will change until marked as FINAL. **The closing date for revisions is 15 October.** -* Publication here is an invitation for community collaboration and co-creation. -* To engage on this content, visit the **\#governance-proposals** channel on the 0L Discord (link at bottom right) -* Once this Proposal is finalized, it will be the subject of Voting on the Radical X Change platform. If you do not yet have credentials, visit the **\#rxc-voice-discussion** channel on the 0L Discord and make a request to join. -* **Voting opens 17 Oct and closes 22 Oct** diff --git a/docs_old/archive/proposals/scorpions_claw_proposal.md b/docs_old/archive/proposals/scorpions_claw_proposal.md deleted file mode 100644 index 5ab4a8f4..00000000 --- a/docs_old/archive/proposals/scorpions_claw_proposal.md +++ /dev/null @@ -1,259 +0,0 @@ -# Scorpion's Claw Recommendation - -## Community Wallet Analytics and V7 Hard Fork Parameters [DRAFT] - -April 9th 2024 - -# TL;DR - -Operation Scorpionโ€™s Claw identified 4.012 billion LIBRA involved in instances of abuse of the community wallet tooling; approximately 4% of the total supply. - -A methodical approach was used to programmatically identify participating accounts. The endeavor took four weeks because - -- new tools were developed -- new technologies implemented -- platform software updated - -The result is a list of 436 accounts. If validators decide, they can now run a version of a network aiming to exclude dishonest accounts. The dishonest accounts which currently contain 3,768,939,592 LIBRA. - -There was a handful of abuse cases. However, the vast majority of the exploit was conducted by a long-term community member who has publicly declared ownership of the accounts originating the exploit. - -- 6DA2B828F3018637379203940C639A95 -- 27E9577869ADFD677DBA9C940DEECE0A -- 988B8C3B7E55B6E5126884E02C8F166E - -A hard fork is recommended, and should happen with a validator ceremony open to the public and using a clean database using the version 7.0.0 software release. - -![image](https://lh7-rt.googleusercontent.com/docsz/AD_4nXfpdWi_O_kHFqEKhvBDfr41QGlcBVH2As0u3xr5Hd0Fxb0IN9N8rBHfvFI5u76rOGSKZZFa36kWdY77XqVWhpRhSgptePszHNlvZJ-tptwfzZsp-WNkvVQLQyg4JTAe2N-uZDuTfhuO2I5XAuao1-1q84B1?key=UdkA8jBMllBve2WagZXXwA) - -# What Happened - -In preparation for the release of the 0L Network v7 Mainnet, analytics contributors ran a comprehensive on-chain analysis of all user-generated events โ€“ code named โ€œScorpionโ€™s Clawโ€. This meticulous examination revealed several instances of abuse, predominantly to the Donor Voice accounts ("community wallets") which are a great source of pride of the 0L community. - -Before a report on these abuses could be completed, the rogue players discovered the operation was underway and began to drain accounts into OTC markets. Some validators responded by stopping their nodes, preferring to wait for the final report and remediation recommendations than to continue participating on a network with that behavior. Many community members were interested in a Hard Fork. This report provides the facts, and basis for which a hard fork could be conducted. - -Operation Scorpionโ€™s Claw identified 4.012 billion LIBRA involved in these instances of abuse, or approximately 4% of the total supply. - -In this report, a list of the accounts involved in the abuse has been developed by strictly adhering to the following goals: - -- A deterministic approach for inclusion criteria. -- Maximum removal of misappropriated supply. -- Minimal adverse impact to uninvolved parties. - -This endeavor yielded a final list of 436 accounts, holding 3,768,939,592 LIBRA. - -Scorpion's Claw proposes that on a new network, these accounts will be excluded by being rendered inaccessible. As such, the associated supply will be permanently removed from circulation. These actions signify an exclusion rate of the total amount of dishonestly appropriated coins of 94%. - -As with any hard fork the prior software would remain available to those who wish to continue on the prior chain. Though the recommendation of this report is that such a chain would not be popular with users for social and economic reasons, users and validators remain free to use that version of the chain if they so choose. - -## Background - -### Design Philosophy - -The 0LNetwork community champions self-correcting systems instead of rigid white list driven systems with authoritarian control. Many 0L designers are informed by Karl Popper's vision of an open society and naturally self-correcting systems. This open approach to design and operations, while prone to exploitation, is essential for progress and encourages boundary testing that allows policy to evolve naturally. Exploitation and innovation are often distinguishable only in retrospect so open systems are necessarily open to what will later prove to be fraud. Eliminate any opportunity for exploitation and one also eliminates any opportunity for evolution. Exploit and evolve. We regard the tradeoff with equanimity. - -Blockchains are probabilistic, not deterministic, systems. Hard forks in this paradigm are viewed not as indicators of failure nor guarantees of success, but as strategic adjustments that are vital to the longevity and success of a robust network which is resistant to abuse and central control. - -0L's Approach to open policies: - -- Emphasize the absence of absolute guarantees, lean on probabilities. -- Reject the need for foundational authority, embrace open participation. -- Recognize the constructive role of exploits and boundary-pushing by participants. -- Accept hard forks as evolutionary steps within the policy framework, aimed for continuous improvement. -- Invite a dynamic interaction with policies, where challenges are opportunities for advancement. -- Underscore the importance of adaptability and innovation in navigating open policies. - -In this paradigm hard forks are viewed not as indicators of failure (nor success) but as strategic adjustments that are vital to the longevity and success of a robust network. - -### 0L Network Policies - -#### Slow Wallets - -Ordinary wallets donโ€™t limit transfer amounts and have no balance restrictions. Transactions are immediate in the typical wallet a user would initialize (e.g. in Carpe). - -Early participants in a network may receive generous subsidies, but the chainโ€™s policies should be designed in such a way as to prevent early participants from dumping on less sophisticated users. To address this need, rewards are sent to Slow Wallets (SW) rather than regular wallets. All validator node accounts, where a majority of rewards flow, are Slow Wallets. Slow Wallets have a drip mechanism that unlocks its balance in increments of 35k coins per epoch until the full balance eventually becomes unlocked. - -#### Community Wallets - -0L Network chain provides tools and patterns for communities to self-fund their activities with LIBRA. One pattern is the Donor Voice participatory payments together with Matching Donation Index, a.k.a., informally "Community Wallets". - -Unlike traditional systems, the core innovation here is that there is no whitelist or global governance structure. 0L Network had no pre-mine state, and designs such as "founder rewards" are antithetical to our design philosophy. - -A Community Wallet (CW) is instantiated not only with a number of on-chain tools (smart contracts), but also with off-chain commitments. Without going into further detail, a user could create a CW (on chain), and ask for donations (off chain). Those donations would also serve as a way to index a Matching Donations list, which validators and other contributors could opt-into (more below). - -Notably, this open system is probabilistic, it was known in advance that it was likely that this would be abused (and as you see below, it was). So there are a number of conditions a CW owner, opts-into by instantiating Donor Voice covenants on their account: - -- That account can only transfer coins to a Slow Wallet -- Proposed transfer takes three epochs (days) to finalize. -- During this period, Donors to have the opportunity to veto a transaction. -- Sequential vetoes to the account will freeze it from doing future transfers. -- Since V6.9.0, Donor Voice enabled accounts are required to be multi-sigs. - -The astute reader will notice, the probabilistic equilibrium depends on players. - -With an insufficient number of players observing Donor Voice accounts, or misplaced trust in observers of those accounts, abuse will take place. This is not a surprise, and was known from the start. A trade-off in playing open games. - -#### Match Index - -In many blockchains there is programmatic removal of coins from supply. Without going into much detail, there are cases when a user should pay competitively for a resource (e.g. transaction ordering), but the cost of providing that value is not proportional to the fee. One pattern is to exclude from the new network - colloquially, โ€œburnโ€ - the difference, and remove it from circulation permanently (see for example Ethereum's EIP 1551). - -Typically the reason for burning instead of redirecting, is that burns prevent a kind of exploit loop where attackers can harvest the redirect. This is true, but it is also a missed opportunity and 0L Network proposed a market driven experiment. - -There is also an opt-in alternative built into all accounts, that allows any user to redirect burns attributed to their accounts to community programs. Strictly speaking: a Donor Voice enabled account usually elects to be a part of Matching Index. This means instead of permanently removing the excess coins, validators can use them to fund any community's programs. - -When a miner or validator opted into making matching donations to a CW, certain regular programmatic removal of coins, would instead recycle coins to the Match Index. (People have compared this mechanism as akin to implementations in the crypto industry of Quadratic Finance, without the quadratic nature of votes). - -### The Equilibrium - -The intersection of Community Wallets and Matching Donations was designed to create a healthy tension: - -- Community Wallet Creation: Any community member has the power to create a Community Wallet, allowing for community participation in a diverse set of initiatives. -- Influence through Donations: By donating to these wallets, individual community members can influence the allocation of matching donations. This system is designed to encourage community support. - -To the objection that more controls were necessary, the old adage of payment processing applies: "I can promise you zero fraud, as long as you receive zero payments". - -#### Boundaries and Consequences - -We've mentioned on-chain constraints to these accounts. It's also worth highlighting that the economic game involving community wallet, exists offline too. The blockchain serves as a coordination layer for the game, it is not the boundary of the game. All users of community wallet tooling should have the expectation that the laws and norms of society continue to apply (code is not law). - -- Social: Community backlash or loss of trust among peers. -- Legal: Potential legal actions based on the severity and nature of the manipulation. -- Hard Fork: In extreme cases, the network might undergo a hard fork โ€” a significant change to the protocol software and database which contain any rules the new network participants choose to enforce, for example: dropping accounts. - -# The Exploits - -This section explains the three types of abuse by community wallet creators which led to the hard fork decision. - -### Harvesting - -The Harvesting exploit involves skewing the matching donations algorithm by donating to a community wallet under the control of one validator with the only purpose of collecting coins from unsuspecting Match Index donors. - -- Harvesting is the act of creating a Community Wallet, then: - - Creating multiple accounts (usually Validators) - - Programming them to funnel their donations and locked coins to the CW they control. - - By doing so, the bad actors are increasing their CW balance while also creating the perception their Community Wallet is highly valued and directing more donations from the rest of the validators and the community as a whole. -- The image below is an example of the harvesting exploit. The blue nodes (validators), made AUTOPAY (blue lines) to a community wallet (orange node). In the case presented below, you can see two CWs that the validators that participated in the Sybil attack donated to (one above the validators, one below): - -![image](https://lh7-rt.googleusercontent.com/docsz/AD_4nXdDv0XeO11HLUR0NFbfKZkIMu33cTFNOtVs8jrwbHF45XecHE4tZO7MGQBUeeOIHGUAXh6G2cB5oqCxKdHVsRQh41wjG5r0OIEthoJwlz2-HYC78Ic5EDcNfp8a7sYfq9X6VXbVogCm3nyWrqYs9NljeDqT?key=UdkA8jBMllBve2WagZXXwA) - -### Spraying - -Spraying exploits circumvent the standard Slow Wallet time-locking algorithm by dividing payments into several Slow Wallets. - -- By design, a Community Wallet only makes payments to a Slow Wallet. - - Coins that are sent from CW to a SW first enter a โ€œbucketโ€ of โ€œlockedโ€ coins. - - They vest and then eventually transition to an unlocked state at a rate of 35,000 coins per epoch. -- Spraying is the act of creating multiple Slow Wallets and then sending CW_PAYMENT to them in parallel. Doing so linearly increases the number of unlocked coins. Instead of the allowed 35k unlocked coins per epoch, this exploit multiplies the effect by the number of slow wallets involved in the exploit. -- In the image below, the purple nodes represent slow wallets, and the green lines represent CW_PAYMENTs. In this case 2773 payment events were made to 433 slow wallets. - - That means that every epoch, the owner of that network accumulated 15.1 million unlocked coins. - -![image](https://lh7-rt.googleusercontent.com/docsz/AD_4nXdedjYc4qNdnT7RzmvLX2vZNgrF0SiobpUAFrQT-X3k69OxssdhXIE0FXbblYocdKintniwjcMx9tde51PD587GAJaABy6J8rFkwQgnClMVj_KH1tHTvC5YBFvCJJMB2ssQGrBiW3jPRR9lq8EXwBjyinQ?key=UdkA8jBMllBve2WagZXXwA) - -### Transfer Bug - -A regression to the codebase was introduced during the v6.9.0 upgrade. - -- The codebase regression manifested in the ability of a CW to make ordinary transfers. This meant bypassing all Donor Voice governance including donor observability, and restricting to Slow Wallets. -- The bug exploit can be seen in the image below with the red lines (transfers) from the CW (orange) to the nodes around it. In this particular case, you can see it exhibits also the first (multiple validators donate to it) and second exploits (making many payments to a multitude of Slow Wallets). - -![image](https://lh7-rt.googleusercontent.com/docsz/AD_4nXdg4tqkagkrHnHtGSOaOQgul_UDCLG2v1RFp3R1eKigc8Y3Psx6XsAeClqxwkF2nnvSFciXTP2hslnlOvMZiw2EaatK0dacqEncm2JRL3-W9c6xQOTbNTcbYoRgA1Aj-1Pl6VPW3i0I3WFkt-kDtO8B9ION?key=UdkA8jBMllBve2WagZXXwA) - -# CASE 1 Principal Exploit - -We will not cover each exploit in detail. However CASE 1 is exceptional because of the exploit size, there were approximately 3,614,811,756 (3.6 Billion) unlocked coins in possession of an individual (the largest unlocked coin stake by perhaps 30x). This is approximately 3.6% of the network supply. - -### Principal Accounts involved - -There are many hundreds of accounts created by a single exploiter. This is verifiable by observing the path of account creation from a seed set of a few accounts. - -![image](https://lh7-rt.googleusercontent.com/docsz/AD_4nXfiR_6nWttmM-i-0e5digE-8N3Z3HfFC1cQZtQR0Jy3imt67q44yYlFVMgKsp7vJN1iP6af1pfNBxbGQdy3kF7wBJrmEstINS4NaTCorV3tks6jtYr8kemVaK_f_u3W_9aGiB06Q6xLnVFIQLj_tiO9KWyy?key=UdkA8jBMllBve2WagZXXwA) - -If the relationships of these few nodes are expanded, the flow of funds goes through these nodes: - -![image](https://lh7-rt.googleusercontent.com/docsz/AD_4nXd2GfTBgsrE6jEFLkeSFOyQJjaRaNyQb5FuBgV1ExEoMjf489bfdS9WKX4o8B7khcS_ibHawRgYAvZLInFWt76e6heG-Y24kA5XrT-W_oWzZ5Nuz1jj1Je42ou5bEACLroPMZgszHp3EDoNQccJCcv2bCE?key=UdkA8jBMllBve2WagZXXwA) - -#### Sham Community Programs - -The community wallets involved in this case are: - -- 7B61439A88060096213AC4F5853B598E -- 5E68026887147DE0EA9CA90962C25A41 -- 97DCBC6BFAA7EDF00F9002DAAED49C46 - -There is no information publicly available about these "community" programs. Different from other credible and well regarded programs in the community. Their principal source of funding was from "validators" nodes which the individual publicly associated themselves with. Due to the nature of Match Index (described above), many other validators became unwitting contributors to these accounts (the "harvesting" exploit). - -#### Sybil Validator Accounts - -Community wallets could not reasonably accumulate much capital unless they solicited donations from many people. But if an individual had acquired access to many "validators" with high reward potential, they could do so. (Note, acquiring multiple validators was also outside the stated norms of the community. Several validators were notified publicly that you should not try to run multiple validators even though you might be able to get around some of the constraints). - -In this case, the exploiter had ownership of the following validator addresses: - -- 6DA2B828F3018637379203940C639A95 -- 15B291FFCA97895D726E8AA9A5BE6A2A -- 5DC8C3878E99E9FD12EBDEFA1803D332 -- C5162C65FDE8C9D9CA9B564E41A54003 -- 988B8C3B7E55B6E5126884E02C8F166E -- 7D299BF3D624E937C23302D8B5E3A1B2 -- 99E4EE712E2A57F694344D288A0FC27A -- 9F1D8C66883768F167A097FF4C58DE88 -- C0FFEE1A3393516D27B72B28464EAA5F - -# The Hard Fork Goals - -Once validators realized the magnitude of the exploit, they and core contributors responded by stopping their nodes preferring to await a full analysis and recommendation. - -The recommendation here is to perform a hard fork of the 0L Network, which maintains all properties of the canonical chain except that it does not migrate the accounts involved in the abuse of the systemโ€™s hardcoded rules and prevents the abuse of those hardcoded rules from taking place again. - -Punishment is not an end-goal. The recommendation is to simply remove abusive accounts, while perhaps setting a non-binding social precedent signaling that a decentralized group of validators are capable of taking, and willing to take, coordinated action to prevent abuse and will not run software that allows abuse. - -# The Process - -The first part of the process involved defining the exploit types. The effort had three key objectives: ensure accuracy, capture as much questionable activity as possible, and avoid penalizing innocent parties all while still being deterministic. - -The Goals were to: - -1. Find all the community wallets that participated in the defined exploits. -2. For each of them, via pattern matching, identify and collect a list of the nodes that participated in the scheme. -3. Identify edge cases where the common patterns did not apply or the scheme operator attempted to obfuscate their actions or balance by spreading nodes via common โ€œsuperspreadersโ€ like the Discord onboarders. -4. Ensure no common, widely known accounts were present on the list such as Discord onboarders. -5. Leave every harvesting case with a single validator node (both as a show of grace and to reward their legitimate contribution to the network). -6. Applying a 200K LIBRA balance threshold to reduce the impact to innocent parties who might be caught up accidentally in the exploit. This approach led to 45.58% of the accounts being excluded from further examination, ensuring the focus of remediation on more chief offenders (see table A in appendix). -7. A single database command should generate a list of accounts without human intervention. - -This whole process was written in several Cypher language (graph DB) queries and packaged into a Python tool that can be run by anyone to produce an identical checksum of the final list. This tool and the queries have been made public in the following directory on GitHub: [https://github.com/0LNetworkCommunity/scorpions-claws](https://github.com/0LNetworkCommunity/scorpions-claws). - -# The Result - -- 436 accounts excluded from new network -- Total LIBRA excluded from new network (โ€œburnedโ€): 3,768,939,592 -- Circulating LIBRA burned: 1,419,359,988 -- Locked LIBRA burned: 640,266,766 -- Community Wallet LIBRA burned: 1,709,312,837 -- Community Wallet excluded from new network: 6 -- Historical validator accounts excluded from new network: 11 - -# Actions Needed by The Coin Holders - -No action is required by community members who were not involved in the exploits. The transition to the hard fork and all subsequent version upgrades will occur seamlessly and automatically. - -# Other Mitigations in Place - -What does the future look like and what more needs to be done? - -- The Bug exploit was fixed in January 2024 in an on-chain upgrade. -- A new off-chain monitoring infrastructure will be built post v7. - - This will improve network visualization and investigative capabilities. The tools that have been developed and utilized during this exploit analysis, will be available soon for public use. -- A dedicated Community Wallets page in explorer will provide valuable insights and live CW activity. - - The community and contributors will continue to report any discovered exploits, rather than taking advantage of them to the detriment of the rest of the community. -- There is no more easy money left. - - A majority of the exploits occurred during a time in the evolution of the network where exploits like harvesting could be rewarded. That time has passed. - -# Acknowledgments - -Special thanks to the Scorpion's Claw task force and all the contributors who worked tirelessly over weeks to resolve these issues on behalf of the extended community. Your commitment to the network is greatly appreciated, and the community is very thankful for your efforts. - -A very sincere and heartfelt thank you also to the wider community for your patience and support throughout this process. - -# Appendix - -Scorpionโ€™s Claw Farm Report: [https://docs.google.com/document/d/e/2PACX-1vQXu7IISWJIAYQ1OG--ETtdaqE7tYG5Gs0kxDkwfRWZAD0W7SFVdb_EgoN8IqHyTj3DXIhF1okYLFT2/pub](https://docs.google.com/document/d/e/2PACX-1vQXu7IISWJIAYQ1OG--ETtdaqE7tYG5Gs0kxDkwfRWZAD0W7SFVdb_EgoN8IqHyTj3DXIhF1okYLFT2/pub) diff --git "a/docs_old/archive/proposals/spring_forward\302\240.md" "b/docs_old/archive/proposals/spring_forward\302\240.md" deleted file mode 100644 index 8653bd82..00000000 --- "a/docs_old/archive/proposals/spring_forward\302\240.md" +++ /dev/null @@ -1,155 +0,0 @@ - -Growth requires challenge.ย  - - - - -There was plenty of such fuel over the last several weeks, challenging our community to run a functional and fair network that is more poised for growth. This announcement will detail what has happened, how we addressed it and how, along the way, we solved a number of different problems and improved prospects going forward. - - - - -On 9 April 2022, the 0L Network halted. Multiple factors combined to create the incident; factors that started small and cascaded until the entire network ceased to produce blocks. While the detailed causes and the technical forensics have been discussed at length in our community meetings, the important point to raise here is that the halt was avoidable โ€“ or rather would have been avoidable โ€“ had a sufficient number within our validator community been more attentive to their machines and taken steps in a timely fashion. Better coordination is a key learning derived from this event. - - - - -With the network stopped, the community decided to take the time to make some major changes and bring back a network that was better and stronger and more aligned to the broader communityโ€™s interests. **As you read this, the network is back, with a new set of features and a richer set of options for developers, Carpe miners, and the community as a whole.** - - - - -Among the enhancements weโ€™ve launched with this new version of the 0L Network: - - - - -### **Carpe Enhancements** - - - - -Together with this network upgrade, we will shortly be releasing a new version of the Carpe wallet and desktop miner. With this release, Carpe will attain full wallet functionality, with the ability for users to send and receive coins using a standard wallet interface. The new release is in testing now and will be announced soon. The Internet of Value needs money in motion. - - - - -### **Make Whole** - - - - -With this upgrade, we have set up a methodology for Carpe miners to claim coins that were under-paid to them in several past epochs due to a network bug. The Make Whole proposal has already been approved by the community, and we have set up a process that can be executed easily from inside Carpe to do so (you can learn more about this, and the new version of Carpe, once the release date is formalized). - - - - -### **Slow Wallets** - - - - -Slow wallet holders, particularly the members of our Hustle Karma workforce, will be pleased to learn that we have also used this upgrade to ease limitations on slow wallets. As of today, you can use your Carpe slow wallets to move coins! Daily transaction limits remain in place for slow wallets, at the level of 1,000 Libra per day. (Note that the daily transaction limit parameter is subject to adjustment by the community at a future date.) The goal is to balance active labor participation and value accrual with fair vesting and spending. - - - - -### **Recovery Tools** - - - - -A new set of recovery tools and workflows to make the network better able to recover from shocks in the future. There were a number of refactors to the writeset-tool, which enables a halted network to apply transactions at rest to upgrade the state machine code, update validator set, trigger new epochs, and enter recovery mode. Future halts could have very minimal downtime if the root cause is found quickly. - - - - -## **Addressing the Larger Problem** - - - - -The tools and actions listed above are important and worth celebrating. However, we have a larger social issue that needs resolution โ€“ that is, the negative impact of passive validators.ย  - - - - -The recent outage shows the need to take action to better align validator incentives with the best interests of the broader 0L Network community. There is a very good argument that the recent network stoppage was less a technical problem than a problem of misalignment of incentives and expectations. We need to take steps to assure an engaged, professional validator set and we also need to change the competitive dynamics for validators in order to disincentivize passive validators.ย  - - - - -To tackle the first issue, we are implementing a new approach to validator set selection. At the launch of the network, validators were entitled to invite whomever they chose to join the validator set. The system had no checks in place, other than a rate limit on how frequently invitations could be issued. We initially counted on social pressure and common sense to guide our validators to select individuals or organizations who were able to manage their nodes to a professional level, and who would respect system requirements. - -Unfortunately, we now have experience showing that a more rigorous approach is needed. Indeed, the initial failures that began the cascade that led to the most recent network halt occurred first with the nodes that were under-provisioned and not in line with our published system requirements. Those failures were then complicated by many of those validators failing to be responsive to their machines and take remedial steps to recover from the failure. - - - - -Going forward, we are layering in a โ€œvouchingโ€ system for validator set selection. At every epoch the system will check that each validator entering the set has endorsement by at least 4 existing validators of different "ancestry" . We mitigate the sybil issues by checking that the vouches come fromย  different โ€œfamily treesโ€ (i.e., who onboarded them). Every epoch, you can only join the validator set if you have at least 4 peers known to be good actors vouching for you. To facilitate this requirement, we have created an onchain permission tree that makes it easy to trace the lineage of individual validators.ย  - - - - -### **Funding the Community via Proof of Burn** - - - - -The second issue โ€“ the competitive dynamics of the validator class โ€“ is somewhat more complex. The goal is to make the cost to exist as a validator higher, and thereby disincentivize passive validators (free riders). To accomplish this aim, we are making two changes. - - - - -First, we are putting in place a more expensive Proof of Burn mechanism. At launch, Proof of Burn was a fixed and insubstantial amount: Each validator was charged 1 coin per epoch to join the validator set. We also implemented a voluntary autopay function that encouraged validators to redirect a portion of their rewards to community wallets. The mechanism was 0Lโ€™s answer to how to capitalize the systemโ€™s growth and expansion in the absence of outside capital.ย  - - - - -By increasing the Proof of Burn we can also automate community wallet funding by making it simpler and more seamless for those who opt-in. Weโ€™re increasing the burn from 1 coin to 50% of validator rewards. Those funds will be distributed each epoch among the community wallets based on donations to those wallets. Validators also have the option to give more than 50% if they wish, and if they do not want to divert the funds to the community wallets, they can elect to have the coins burned. Note that this change simply streamlines the autopay functionality that has been tested since the Genesis of the network. - - - - -Second, we are closing a loophole in the systemโ€™s capitalization game by making the Proof of Burn apply to both active and inactive validators. This approach not only helps provide critical network funding, it also incentivizes validators to participate in consensus in order to earn rewards and avoid the clawback of their previously earned coins. We expect this change to be controversial with some people and we have suspended the implementation of the Proof of Burn on inactive validators for 10 epochs. During that time, people can learn more about it and discuss. If there are substantial objections, the issue will be debated and revisited.ย  - - - - -The changes to the validator onboarding and economics may not be guaranteed to reach the desired state, but directionally, they move us closer to the goal: Engaged validators who are stewards of the chain. Implementation of new types of economic incentives and games (for example, delegation) could build on these changes, make the economics more interesting for Carpe miners, and also help disincentivize inattentive validators.ย  - - - - -## **Next Steps** - - - - -At present, the network is in Recovery Mode and Carpe miners are able to start the app and check balances and have minimal interactions, but not mine their Tower. Recovery Mode suspends all economic activity to allow for testing and network stabilization. (This also disincentivized actors from front-running or otherwise taking advantage of skewed economics from network halts.) To be clear, while the network is in Recovery Mode no rewards are being paid to anyone โ€“ not even validators. One Saturday, 30 April, the network will open again for Carpe miners and we invite everyone to come back in. - - - - -Also, as noted above, the Proof of Burn on inactive validators is being held in abeyance until Epoch 185\. During that time, if there are objections to this approach, they need to be discussed in the community to determine whether action should be taken.ย  - - - - -## **In Conclusion** - - - - -Blockchain are infinite games. The game itself evolves and adapts. Passivity and paralysis are not an option. - - - - -**The 0L network is live and running, as is our global community working towards the mission of a transparent, participatory, liberating, open blockchain network for all. We have dealt with the challenges of the moment to create a stronger foundation for the future, and we will continue to evolve the technology, social contracts, and norms of the project to best accomplish such a mission. Your voice is heard. There are more rewards for Carpe miners, as well as a hard commitment for 50% of the funds to flow to community-building wallets that reward participants that build along with us.** - - - - - -**Carpe diem. โœŠโ˜€๏ธ** diff --git a/docs_old/archive/proposals/team_arctika_recommendation.md b/docs_old/archive/proposals/team_arctika_recommendation.md deleted file mode 100644 index 9441d268..00000000 --- a/docs_old/archive/proposals/team_arctika_recommendation.md +++ /dev/null @@ -1,100 +0,0 @@ -**To survive, the 0L Network needs to solve two problems. We need**: -1. Abundant capital for security, and -2. Abundant capital for recruiting talent. - - -And if possible, we should solve these problems in a fashion that does not worsen the inequality between members of the community. -## Much More Capital Is Needed - - -The crypto headwinds are significant: Regulatory pressure, fraud, scammers and a macro economic environment that favors the bears. If the network wants to survive the next decade, without any inflation, it needs to reserve a large portion of the network capital for future purposes. We will need to provision a greater amount than our peers who have inflation. We are of the opinion that the proportion should be as close to 80% / 20% as possible (the math resembles that of venture fund economics). While we strived for that goal, we weren't able to reach that number without massive disruption to multiple user groups. We finally arrived at a 70/30 ratio (70% for growth and ecosystem; 30% held by community members today), which gets us functionally close to the original goal, without system wide disruption of stakeholders. -## How much is necessary for the Infrastructure Escrow Fund (IEF)? - - -We can estimate that, in order to attract validators, the network will have to pay each validator US$4-5k per month (this is consistent with what validators are paid in mature networks with smoothly operating software). In our interviews with professional validators, we arrived at $4,200 as our baseline. See the data in the table, below: - - -![](../../assets/validator-opportunity-cost.png) -The Team agrees that we need to provision for another 7 years of network operations. Weโ€™re roughly three years into the networkโ€™s life cycle at this point in time (1 year in testnet, followed by almost 2 years since Genesis). Altogether, we should make it through at least the first 10 years of the network. - - -Of course, translating a token with no market value into monthly USD amounts requires some assumptions about value. We must take a conservative approach on market cap, for "all weather conditions". Despite what weโ€™ve seen with some of our peer networks, we can't reasonably say that the base case for networks is a valuation of $1B\+ over the next 7 years. Likewise a network worth less than $50M for many years likely leads to extinction. So, the calculations we made assumed a $100M market cap, from which a token value could be extrapolated; this seemed like a reasonable base-case (which could be substantiated further). -At that intersection: 100 validators earning $4,200 per month over 7 years, with a network on average worth $100m, the result is approx 35% of network capital needs to be pre-diluted for sufficient safety. - -![](../../assets/infrastructure-escrow-pledge-sensitivity.png) -### Over-allocation - - -The formula above, and our approach to erring on the side of more rewards, may lead to over-allocation of OPEX instead of CAPEX type activities; so there must be a provision for over allocation (i.e. if the network is persistently worth more than $100M). -#### Policy for Over Allocation - - -The IEF is designed to continue with the V5 policy, that overspending can be burnt: i.e. reclaimed capital. The burn can optionally be "recycled" by validators by sending to an algorithmic matching contract, which distributes to Donor Directed wallets (aka community wallets) which have received the most donations (biased for most recent donations). We recommend this policy continue, such that over-allocation to OPEX and infrastructure, doesn't penalize growth capital (CAPEX). This is compatible with the Proof-of-Fee design where, for example, every epoch there can be a consistent drawdown from infra-escrow, and only the net is paid to validators, and the overallocation is burnt per the policy above. -## Who can contribute? - - -Some category of participants need to pay for these proposed changes. This requires a pragmatic, and not an emotional solution: ***What does the repeated game need for success?*** -We elected to eliminate some options outright:ย  -* **Carpe miners**: There is not enough capital to meaningfully tax those users. Any tax would be symbolic. -* **Worker slow wallets** (e.g., beneficiaries of FTW, Hustle Karma, and other community bounties): Again there is not enough to tax, that would meaningfully contribute. -* **Community Wallets**: Thatโ€™s a bigger topic so, see below - - -### Why Exclude Community Wallets? - - -There's a lot of misunderstanding about Community Wallets โ€“ and the concept is very important to the project for several reasons, not the least of which is regulatory compliance.ย  -0L has no centralized treasury, by design, and for regulatory compliance it has been recommended that we never implement one. Community wallets are an emergent property of the network. The wallets have typicallyย  been created to fund programs for the benefit of the community. Part of their role is to safeguard capital for future uses. The vast majority of them have some language related to: a) safeguarding capital for future use in the network, b) deploying that capital. According to the disclosures of these accounts the capital is not used for personal or company enrichment. -Given their stated role, taxing the community wallets is taxing our growth capital. If you reduce the size of community wallets in favor of infrastructure escrow (IEF), you are reducing the amount of discretionary investment capital.ย  -In the extreme case: If you tax community wallets 100% into the IEF, while we will solve problem one (security capital), we would fail on the second problem (there will be no funds to credibly attract future talent and entrepreneurship).1 -We are left with charging the Validators. -## How much do we ask validators to contribute? - - -If we keep with the numbers above, Validators should contribute 80% of past rewards towards the future IEF. We think this is acceptable for two reasons: First, there is very little choice if we are to survive, and second, the historical payout was not reflective of market conditions and therefore equity favors adjustment.2 -### Disproportionate rewards - - -Our conclusions about the need to address equity were based on data. We conducted a survey to find out how much volunteers have contributed over time, and what is the approximate value of that work. We asked the same of validators, as well as engineers. -The results of our (limited3) research showed that, at the extremes, workers had a cost per coin that was up to 45X higherย  than the costs incurred by the Validators. Another way to look at it, the cost per coin (from lost wages and infrastructure payments) that pure Validators paid was 1/45 that of the top contributors (all rewards considered). That's about a 98% discount4, according to our research numbers. Paying more did not confer the workers any advantage in volume (they were not able to accumulate more share of the network). -After the dilution, Validators are still getting an extremely attractive proposition. Excluding outliers (0D for example) the typical validator accounts still have paid 87% less than the top 10 worker accounts.5 It would be inappropriate, however, to conclude that the workers have been given a superior deal. The vast majority of workers have the majority of their coins from validator work. And those accounts will also be contributing 80%. This can only be corrected by using the community wallets judiciously. -Despite the workers not being explicitly and mechanically taxed, they have already been (e.g., inflation). Even after this intervention, and considering possible uses of community wallets to "make-whole" these workers, in the best case the largest passive validators will have a 76% discount on cost per coin versus the lead engineers. While we can make it better, we canโ€™t fix everything. -Lastly, the most committed Validators will partially reclaim their contributions to IEF if they commit to validating over the long term. By continuing to operate a Validator, a portion of those coins will come back to them. (Note this is the only group of community members that benefits from this mechanism.) -## Budgeting for past workers - - -A related issue is also being addressed in conjunction with the tokenomics adjustment. Prior to the re-basing and the dilution and adjustments outlined above, the Tip Jar and Iqlusion FTW wallets will be distributed to workers. Note that these uses are consistent with the stated aims of the wallets and, at least in the case of the FTW wallet, the amounts should have already been paid out. Failure to pay those out prior to the re-basing would disadvantage those workers. Put another way, the Tip Jar (which 0D has already offered to community purposes), as well as the FTW wallet (which has not made monthly payouts as it was intended to) should "make-whole" the past workers.ย  -We think the proposal increases equity but frankly the main purpose of the proposal is for survival. The increase in equity is a bonus. The only scenario in which everyone is equal is the collapse scenario which none of us want. -## Budgeting for future workers - - -The remaining community programs should focus on the future. There is no formal mechanism, but they can be encouraged to do so by their donors (which are historically validators) through the governance changes to Donor Directed Wallets. -## Conclusion: This is what Good Capital looks like - - -We looked at many models of dilutions and fees. Asking validators to invest 80% of prior rewards into Infra Escrow, very cleanly (even serendipitously) allowed the network to have these properties: -* 70/30 in favor of future network participants. -* Have future capital for Opex (Infra Escrow) and Capex (Community Wallets) split evenly (out of the 70%) in the base case. -* Reduce the gap between worker and validators to 1\.3X from 16X. - - -![](../../assets/summary-dilution-impacts.png) - -We think this allocation, with abundant amounts for future capital, which honors prior workers such that we can continue recruiting for future talent, and sets up all current participants for future success is **unique and exemplary in the industry, and fulfills our mission of creating "good capital" and gives us the best shot at surviving and thriving.** - -ย  -### **โ€“ Team Arctika** (AlexT, Daniyal, Lex, 0D, ricoflan, Wade \| TPT, Zmanian) - - -ย  - -*\*\*Note the Arctika Report was originally published to the 0L Network Discord on 23 May, 2023\.ย See, https://discord.com/channels/833074824447655976/910315033672704090/1110679498288005130* - -\=\=\=\=\=\=\=\=\=\=\=end notes\=\=\=\=\=\=\=\=\=\=\=\= - -1ย That all said, there is an important recommendation we must make for community wallets. Keeping with the October poll, where the network expanded the governance of the Donor Directed wallets, to allow the donors to freeze accounts, this was underspecified. What happens with the frozen account? We think the natural conclusion is that the frozen account should get liquidated into a pro-rata share of the remaining qualifying donor directed wallets. We don't anticipate this will ever be done, but it's important for the game theory of multiparty negotiation of the uses of the community wallets. -2ย A key incident contributed to the second issue, the disparity in the history payouts to Validators. There is an acknowledgement that the Reward Auction in 0L was no longer viable after a partial upgrade in April 2022 (the baseline parameters were not updated after some other policies were updated). -3ย This was done via a Google Form that a number of members voluntarily completed, so it is based on self-reported data. -4ย We do recognize this is a generalization and may not apply to everyone across the distribution, but the data we gathered did support these numbers as a general matter. -5ย Note that our calculations showed that you could achieve equity between the groups, but only at the expense of diluting Validators by 98% โ€“ a non-starter. -6ย Note this โ€œBEFOREโ€ data is from the Cap Table research done by ricoflan in March 2023, so it is not current at the time of publication of this paper (23 May 2023\). diff --git a/docs_old/archive/proposals/the_0l_network_constitution.md b/docs_old/archive/proposals/the_0l_network_constitution.md deleted file mode 100644 index ecd27aa6..00000000 --- a/docs_old/archive/proposals/the_0l_network_constitution.md +++ /dev/null @@ -1,70 +0,0 @@ - -Adopted by Community Polling on 3 May 2022 - - - - -## **Purpose of this Document** - - - - -This document is intended as an exposition of shared values at the heart of the 0L Network Community. The principles espoused herein are provided as a framework for decisions at a macro level and have been drafted to inform the decision process and provide a foundation to facilitate consistent and rational decision-making. This Constitution should be treated as a living document that is extensible โ€“ within the framework of our core values โ€“ as the community grows. - - - - -## **Our Core Values** - - - - -From our genesis, we have avoided the creation of an insider class (like a foundation, a protocol team, or venture capital investors) that might lead us down the path toward plutocracy. By creating an egalitarian community we hope to give the power of this blockchain to those that might do good for both our community and the wider world. We, as a community, seek to empower visionary entrepreneurs who hope to harness our chain to address problems at the intersection of information, economics and social coordination. To that end, we have adopted the following core values, which will serve as the underpinnings for critical decisions and our long term roadmap:ย  - - - - -**1\. Merit**: We are a community of do-ers who believe that those who serve our community and its vision should be rewarded \& given a voice in shaping our communityโ€™s future.ย  - - - - -**2\. Equity:** We are a democratic community that values fairness. We welcome all and actively seek to avoid descending into plutocracy. - - - - -**3\. Diversity**: We strive to build an inclusive and diverse set of stakeholders, as we recognize that a diverse community is a resilient community. - - - - -**4\. Network Integrity**: We take the state and security of the network seriously and will not lightly take actions that impair or threaten them. - - - - -**5\. Decentralization**: The project should always strive towards decentralization. - - - - -**6\. Permissionless:** We will strive to keep the network and the community open to all. - - - - -**7\. Do Good**: We believe that generating positive social impact is everyoneโ€™s responsibility and we pledge a portion of this communityโ€™s output to furthering social good and humanitarian relief. - - - - - - - -**Related Documents** - - - - -* [Libra Liberated](http://openlibra.blog/2021/11/15/libra-liberated/), (15 Nov 2021\) diff --git a/docs_old/archive/technolgy/carpe_desktop_app.md b/docs_old/archive/technolgy/carpe_desktop_app.md deleted file mode 100644 index c17d606e..00000000 --- a/docs_old/archive/technolgy/carpe_desktop_app.md +++ /dev/null @@ -1,39 +0,0 @@ - -This desktop app is a combination wallet and light miner. It connects to the 0L network and lets you create accounts, do some account management, and participate in the network by mining coins. It runs on Windows or Mac and can be used on a wide variety of desktop and notebook computers. - - - - -Like any account-based blockchain, any new account address you create in the Carpe app will be inactive (will not exist on the chain). For the account to become active, someone needs to send you at least one coin to it; that is the essence of the onboarding process. Until that happens your account does not exist "on chain". If you don't know anyone yet on 0L, come into the Discord chat and just ask anyone there. Many people will be happy to help get you onboarded. Otherwise the app should guide you through it. - - - - -Stay tuned....we're about to announce some great new enhancements to the wallet functionality! - - - - -ย  - - - - - - - -## Download Carpe - - - - - - - -The button below will take you to the Github archive for Carpe, where you can select the right package for your operating system. - - - - - -[Visit Carpe on Github](https://github.com/0LNetworkCommunity/carpe/releases) diff --git a/docs_old/archive/technolgy/developer_resources.md b/docs_old/archive/technolgy/developer_resources.md deleted file mode 100644 index 20b6a0d3..00000000 --- a/docs_old/archive/technolgy/developer_resources.md +++ /dev/null @@ -1,50 +0,0 @@ - -A succinct collection of documentation, tools, and tutorials on 0L, the Move Smart Contracts Language, and the original Diem codebase. Note that the links will open in a new window. Please contact us if you'd like to add/correct anything on this list. - - - - - - - -## 0L Native - - - - -* **[0L Core Dev Documentation](https://github.com/0LNetworkCommunity/libra/tree/main/ol/documentation/core-devs)** : The official documentation for the project, hosted on GitHub. -* **[0L Move Language Documentation](https://github.com/0LNetworkCommunity/libra/tree/main/ol/documentation/move-dev)** : Documentation for the Move smart contracts language, as implemented in the 0L Network. Docs hosted on GitHub. -* **[0L Dev Discussions on Discord](https://discord.gg/5JgdYka2nE)** : Visit the 0L Discord server to view the Developer Discussions channel. -* **[0L Network Roadmap](https://github.com/0LNetworkCommunity/libra/wiki)** : The current project roadmap, on GitHub. -* **[0L Developers' Project Board](https://github.com/0LNetworkCommunity/libra/projects/6)** : List of open projects being coordinated by the 0L Engineering Working Group. - - - - -## Move Smart Contracts Language - - - - -* **[Move Tutorial](https://github.com/diem/move/tree/main/language/documentation/tutorial#Step0)** (GitHub) : Move tutorial that provides an overview of using the df-cli and creating a basic coin contract. -* **[Awesome Move](https://github.com/MystenLabs/awesome-move)** : An excellent collection of Move resources from our partners over at Mysten Labs. Hosted on GitHub. -* **[The Move Book](https://move-book.com/)** : Very nice attempt to create a comprehensive Move language resource. Most extensive one stop site for information on Move. -* **[Move Intro from Diem](https://developers.diem.com/docs/welcome-to-diem/#write-smart-contracts)** : Useful tutorials from Diem on smart contracts, modules, coin creation, and more. -* **[Move Design Principles Video](https://www.youtube.com/watch?v=EG2-7bQNPv4)** : YouTube video explaining the features of the Move language, how it compares to other blockchain programming languages and why some of the design decisions were made. -* **[Official Move Language Documentation](https://diem.github.io/move)** : The official Move smart contracts language documentation, hosted on Github. -* **[0L Move Language Documentation](https://github.com/0LNetworkCommunity/libra/tree/main/ol/documentation/move-dev)** : Documentation for the Move smart contracts language, as implemented in the 0L Network. Docs hosted on GitHub. -* **[Move CLI](https://github.com/diem/move/tree/main/language/tools/move-cli)** : The Move command-line interface (Move CLI) is a tool that provides an easy way to interact with Move, to experiment with writing and running Move code, and to experiment with developing new tools useful for Move development. Hosted on GitHub. -* **[Dove - A Move Package Manager](https://github.com/pontem-network/dove#dove)** : Move language package manager for Diem and Pontem networks, hosted on GitHub. -* **[Move Analyzer](https://marketplace.visualstudio.com/items?itemName=move.move-analyzer)** : A Visual Studio language server and basic grammar for the Move programming language. -* **[StarCoin Move Contracts](https://github.com/starcoinorg/starcoin/tree/master/vm/stdlib/sources)** : GitHub resource for Move smart contracts as implemented on the StarCoin blockchain. -* **[Dfinance Move Tools](https://github.com/dfinance/move-tools)** : A toolset for Move language projects from Dfinance. Hosted on GitHub. - - - - -## Diem Resources - - - - -* **[Official Diem on GitHub](https://github.com/diem/diem)** : The official Diem repository on GitHub. diff --git a/docs_old/archive/technolgy/technology.md b/docs_old/archive/technolgy/technology.md deleted file mode 100644 index f188edbc..00000000 --- a/docs_old/archive/technolgy/technology.md +++ /dev/null @@ -1,356 +0,0 @@ - -## What we are doing - - - - -0L's technology strategy is to stay as close as possible to the Libra/Diem code base. - - - - -This is because fragmenting the technology products on offer will lead to confusion, and eventually to lack of maintenance and stagnation. This is best for the wider open source ecosystem these tools extend and depend upon. It's also much more efficient on resources. Libra/Diem is a massive project, and simply keeping up to date with the code updates requires a dedicated team. Let alone making additions. Separate from Libra/Diem, The 0L project on its own has contributed tens of thousands of lines of new code. - - - - -So the forking strategy is simple in concept: take the unmodified Diem code, and import it into the 0L project and add layers of features. Though it's not that simple in execution because of the nature of the code base. We have to insert many changes in strategic places of the diem-core code, in order for the 0L layers and side-cars to work. In short, it's not a simple code merge, it takes about two weeks from start to finish to incorporate a new upstream Diem release into 0L. - - - - -## What we inherited - - - - -The Libra/Diem platform is a spaceship on all accounts. There are engineering breakthroughs throughout the project. The architecture is sensibly designed, and expertly assembled. This is the merit of the Facebook engineering team (who as individuals appear to true believers in the power of these technologies, and one should make no assumptions of their views on corporate strategy). - - - - -This is a non-exhaustive summary of the key features of the Diem architecture that are worth paying attention to. We'll take it from the top of the stack to the bottom. - - - - -### The Move Language - - - - -The smart-contract language of the platform is called Move. It is the most unique breakthrough of the team. This is a language that is designed to be extremely safe in adversarial environments, and for hurried, less experienced developers. It's a very ergonomic language, it's easy to approach it if you have even entry-level coding experience. In terms of safety it incorporates much from the Rust language concepts of "borrowing" memory. The compiler is pretty obnoxious, which is something you want when designing autonomous financial systems. One standout feature of the Move language is built-in Formal Verification. Adjacent to the code you can write specs for invariants which your code must preserve (i.e. this function should never be called by this type of account), and it can be checked during the development and build process. This is unique and powerful. - - - - -### Programming model - - - - -The execution of the smart contract and scripts has some subtle but important safety features. By design what are referred to in other platforms as smart-contracts are in fact "modules" here. Users can publish modules, which any other module or transaction can import. This is important. The transactions are scripts. So compared to Ethereum, much of what happens in a smart contract, can actually be split into long lived code in a module, and transaction-scripts which can import from the module (and other modules). This decoupling allows for powerful composability and reliability. The developer can evolve the application without necessarily needing to upgrade modules every time a new transaction use-case emerges. - - - - -Modules can have "resources" bound to them. A resource can be thought of as an object in memory, but with restrictions: they can only be modified by the module that instantiated them, and are restricted in how they get created and transferred. Writing a non-fungible token is basically just instantiating one such structure, and something like a fungible token, can be done in a handful of lines of code. - - - - -### Standard Library - - - - -This is a minor and easily overlooked architectural decision that is quite powerful. There are many modules that are provided standard by the chain, published to the 0x1 address. This standard library can be imported into user-defined modules and transaction scripts. - - - - -Importantly, much of the logic tangential to consensus (e.g. validator inclusion in validator set) which would ordinarily be done in the protocol layer (i.e in Rust) is actually written in Move and is stored in the application layer. That is, much of the system policies are just state in the chain database. This makes upgrades to many aspects of system management trivial. Notably in Diem's case, this is done by a centralized party (see below how we had to modify this). - - - - -### The Move VM - - - - -This is a purpose-built bytecode execution environment which isolates the Move Language from the state transition core. The unique feature of the Move VM is that it is easily extensible. It's very easy to include a new instruction to the virtual machine, a "native function". The native functions are written in Rust (which is the language of the entire code-base). Below we reference some of the changes we had to make for real-world use cases. - - - - -### Executor - - - - -This is another place where the Libra/Diem architecture shines, and still has opportunity to evolve over the long term. The most important feature of the Execution layer is "decoupled execution". This is an important breakthrough. Typically in blockchains all transactions are handled sequentially, there can be no parallelization. With decoupled execution, on the other hand, the executor service checks if a transaction can successfully be processed in parallel to other operations in the mempool. That is: if the transaction could be executed in isolation, and the state changes are atomic. - - - - -This places Libra/Diem in a rarified company, the transaction throughput is massively scaled because of this architectural choice, and skillful engineering. It also lays the groundwork for further optimizations possible, and likely coming down the path including the Narwhal DAG mempool management paper Facebook released recently. - - - - -### Mempool - - - - -The mempool management is different from typical blockchains where transactions within the mempool are propagated (e.g. with gossip protocol) without guarantees of inclusion by other parties. In Libra, a Validator node receiving a transaction has the task of making sure the transaction is included in all other validator's mempools. This change allows voting on proposals to happen faster, and more orderly than other methods. - - - - -### Consensus - - - - -There's a lot to be said about how consensus happens on blockchains, and we won't attempt to go into any depth here. The LibraBFT consensus is a variation on Hotstuff, itself a variation of classical consensus algorithm pBFT. LibraBFT borrows much from HotStuff leveraging consensus linearity wherein an agreement on a message is reached in a single round. Pipelining of blocks in HotStuff guarantees the finality of the proposed block by the third block following the proposed block. Effectively block production is only gated by the network speed, the speed in which blocks can be propagated to other nodes. - - - - -### Storage - - - - -The database which stores the transactions is based on a Sparse Merkle Tree design called Jellyfish. This is an architecture shared by a number of blockchains. It has the benefit of being fast to search, and occupies less storage space (hashes) than a traditional merkle tree. The storage is backed by a RocksDB key-value store. This is a sensible design. There isn't much to remark here, except that there are still opportunities that can be leveraged from this storage architecture to allow for faster syncing of the blockchain. - - - - -### What had to Change - - - - -The technology we are inheriting is a spaceship. It is also purely infrastructural. There's very little in the way of tooling or smart contracts that are usable in the real world. We assume much of the remainder of the software stack is closed-sourced at Facebook. - - - - -But most importantly, the architecture is designed as a private, consortium chain. For system administration, there is on omnipresent Diem Association account. Yes, a private key that controls many functions including: Freezing accounts (!), selecting validators for inclusion, paying transaction fees to validators, upgrading the system code. This is obviously a non-starter. So a lot of work had to go into making system policies execute in a permissionless environment. - - - - -We also had to add Sybil resistance mechanisms. Typically communities have been choosing Proof-of-Stake as the Sybil resistance method for BFT networks. This is not the route we chose given community growth considerations (as well as regulatory). Elsewhere we've talked in detail about our Delay Towers complement to consensus. Also there were a number of instructions we wanted to add to the MoveVM so that people could write the types of contract they wanted. - - - - -Lastly, there was nothing in Libra/Diem about economics. Meaning, there's nothing in the way of game theory, about how the network is supposed to perform in a permissionless environment. For example: the transactions are metered in USD stablecoins in LIbra/Diem architecture, and paid out by the administrator, and there's no word anywhere about subsidies that may be needed in the absence of meaningful transaction fees. As such there's no consideration to the performance of the validator nodes, all nodes are assumed to be monitored external to the protocol. So we had to rethink a number of things given some of the technical features of the network. The network has novel features, so economic mechanisms we see in other chains would not be drop-in replacements. This was a significant amount of research. - - - - -## Our Contributions - - - - -This is not an exhaustive summary of the changes. 0L contributed about 40k new lines of code to the code-base, not including changes and code removal. It's a summary of what we think makes 0L a compelling network. - - - - -### Removing the Root Account - - - - -This is an obvious decision. But the task propagated into many subprojects. The Root Account is pervasive in the codebase. So we had two things to accomplish: (1\) replace all its functions with a system 0x0 account (2\) Neuter the Root Account where impossible to remove (e.g. in much of the genesis logic). Decentralized Genesis Beginning with Genesis, the Libra/Diem architecture provides good tooling on creating genesis blocks, mainly for testing. For an actual network genesis, the tools assume that there is an administrator that is picking the participants and then setting a layout file. - - - - -In our changes we made it such that an online Github repo acted as a gathering place for anyone who wished to "register" to be part of a genesis. The owner of the repo, would have as a policy in the genesis ceremony, to accept all pull requests or people adding their genesis validator configurations. In our genesis, all candidates had to submit a Delay Tower "proof zero", an initial proof of work. All registrants are expected to provide their own layout file. This means that several genesis blocks (and hence networks) are possible with the initial genesis. After a few attempts and some social consensus a canonical chain will emerge. This may appear unpredictable, but it has the benefit of being a maximally decentralized genesis ceremony. - - - - -### Delay Towers - - - - -We've written about this extensivelyย [in ol/documentation/delay\_towers/](https://github.com/0LNetworkCommunity/libra/blob/main/ol/documentation/delay_towers/delay_towers_0.md). We needed a way to choose what validators were allowed to operate in a validator set. We did this without Proof of Stake. In short, Delay Towers prove sequential proofs of elapsed time. This can be considered a "heavy" identity, enough for the BFT requirements of there being a durable identity, which is not cheap. This was a significant amount of research and experimentation. - - - - -[Read the full paper here on our blog.](http://openlibra.blog/category/canonical/) - - - - -### Hot Upgrades - - - - -While there's a long discussion possible on how network upgrades should be selected (governance), there was no starting place for that conversation, when the system could only be updated by the root account (that we removed). We invented an upgrade mechanism for BFT, which does not require hard forks, nor operator intervention at the time of upgrade. - - - - -Since all system rules are encoded in the application layer in Diem, the code is quite compact, and a proposed new binary could also be stored in the applications layer. Since that's possible it also opens up the binary to be voted on chain, and the code of the upgrade itself, stored on-chain, such that the upgrade can happen without operator intervention. New binaries for the system can be proposed and voted upon by the validators, and if there are โ…” of validators choosing the binary (effectively what would be needed for a hard fork), the changes would be synchronously written by all validator nodes at a coordinated time in the blockchain. - - - - -### Validator Stats - - - - -We had to have on-chain information on the performance of validators. This is critical to designing any economic games around transaction fees and other rewards. - - - - -Fortunately in the upstream code, the block prologue is executed in the Move virtual machine, and allows us to add transaction metadata directly into the state machine on every block. So the 0x0 system address contains information on what validators have voted on a given block, and who the proposer was. We can use this for some naive metering within the state machine. It's a sufficient amount to be able to identify which validator nodes are not performing and apply certain sanctions. - - - - -There is a performance penalty for this, and optimizations are possible. Since Move does not offer higher order data structures (hash tables) the data is stored in tables which are not ideal for traversing. - - - - -### Onboarding of accounts - - - - -In the upstream LibraDiem code, accounts are not created permissionlessly. It starts with a Diem Association Account, which later add Virtual Asset Service Providers (such an exchange), which later create user accounts. So all of this had to be replaced (the code remains in our code base for reference, but is inactivated). Instead, there are only two types of accounts on 0L: end-user accounts (the typical account), and Validator Accounts (who own and operate nodes). - - - - -End user accounts can be created by anyone that already has an account, as is typical with any account-based blockchain. Like in Ethereum, you can create keys for an account offline, but the account does not exist until someone already on-chain sends you at least one coin. - - - - -Similarly for Validator accounts, an account needs to be created by another pre-existing Validator account. There are some game theoretical considerations here which are discussed in the Rulebook. In short, unlike industry practice where the group of validators have to vote on admission of a new member, in 0L any validator can onboard another, but they are rate-limited from onboarded too many. One validator can onboard another every 14 epochs (days). - - - - -Tangentially, but relevant. Any accounts can optionally create different policies on them called Slow Wallets or Community Wallets. This is described in the rule book. - - - - -### MoveVM changes - - - - -We've made some additions to the MoveVM that were necessary for us to implement Delay towers and so that users could write useful financial apps. - - - - -* **Decimal** - we needed a number type that could be used for financial math that could lead into polynomial curves etc. So we added the Rust Decimal library and some initial APIs and their corresponding native instructions. -* **VDF verification** - to verify the Delay Towers proofs we added the ChiaVDF verifier to the VM. The prover is not needed in the VM. The VDF prover can accept a number of parameters (not hardcoded for 0L's use-case). So application builders could leverage it in their own games. - - - - -### Auto Pay - - - - -The ability to create payments in the future, and regular payments as a percent of account balance or of new income. This was a feature requested early by the community. It powers a number of use-cases important at the start of a network. Namely it is useful for anyone that wants to run a community program. In this case an entity or a person is seeking to accomplish a goal or a project, and is asking for donations. Autopay allows for set-it-and-forget-it donations to programs. Most people in 0L use this to send a portion of their mining rewards to programs automatically. - - - - -Autopay can be programmed for: - - - - -* Sending a single payment in the future. -* Sending recurring flat fee payments every epoch (day). -* Sending a percent of the balance every epoch. -* Sending a percent of NEW balance every epoch (e.g. mining rewards). - - - - -Future types of autopay are possible. Autopay has a simple First In First Out Queue, to handle planned payments that go above the current balance or above current transfer restrictions. CLI Lots of tooling had to be written to successfully manage nodes and interact with accounts. Much of the tooling is in early stages given the ground that had to be covered given the complexity of the system. - - - - -### Web Monitor - - - - -a web interface for a Nodes Operator to see reports on the node. Basic chain info: Epoch number, waypoint. Includes Node Health, and account info Performance reports on all validators in set. JSON endpoints to query data, like the node's account profile, epoch. Not to be confused with a fullnode json-rpc - - - - -### Terminal Explorer - - - - -Explorer - a terminal block explorer. This one is mostly for fun. This is a terminal interface for a block explorer to check some vitals of your fullnode or validator node. - - - - -### TXS - - - - -We needed a library for sending different types of transactions. So that it could be imported in other tools. TXS also include a CLI utility to send commands from terminal. - - - - -### Onboard - - - - -This is a library and CLI tool for creating packaging all of the necessary files for a new fullnode or validator account to join the network. Because 0L changed the account creation permissions and logic, there had to be purpose built tooling for it. - - - - -### Restore - - - - -Diem has one significant limitation which is a slower sync time. A fullnode joining an already mature network, will take a long period of time to catch up to consensus. So we had to create tools and a bit of infrastructure to leverage some of Diem's existing backup and restore tools. At every new epoch there is a snapshot taken of the chain, and submitted to a Github repository. Multiple such repositories can exist. When a new validator is joining the network they must begin as fullnodes. The ol restore tool will fetch a snapshot from repository, check it, and deploy it so that the fullnode can begin syncing from an advanced epoch (i.e. waypoint). - - - - -### Carpe - - - - -Last but not least. We wanted all users to be able to participate meaningfully, and on equal footing with a protocol. Since there is a subsidy for creating heavy identities on the chain (Delay Tower), we needed to make this accessible to a diverse audience. The Carpe app, combines a Wallet with a Light Miner, which allows anyone with a desktop whether Windows, Ubuntu, or Mac, to "mine" coins for themselves. [Learn more here](http://openlibra.blog/technology/carpe-desktop-app/). diff --git a/docs_old/assets/infrastructure-escrow-pledge-sensitivity.png b/docs_old/assets/infrastructure-escrow-pledge-sensitivity.png deleted file mode 100644 index 86c6d035..00000000 Binary files a/docs_old/assets/infrastructure-escrow-pledge-sensitivity.png and /dev/null differ diff --git a/docs_old/assets/summary-dilution-impacts.png b/docs_old/assets/summary-dilution-impacts.png deleted file mode 100644 index c24cdaa9..00000000 Binary files a/docs_old/assets/summary-dilution-impacts.png and /dev/null differ diff --git a/docs_old/assets/validator-opportunity-cost.png b/docs_old/assets/validator-opportunity-cost.png deleted file mode 100644 index 008f41bf..00000000 Binary files a/docs_old/assets/validator-opportunity-cost.png and /dev/null differ diff --git a/docs_old/assets/wg-org-chart-example.png b/docs_old/assets/wg-org-chart-example.png deleted file mode 100644 index 97d9c84b..00000000 Binary files a/docs_old/assets/wg-org-chart-example.png and /dev/null differ diff --git a/docs_old/cli-tools/_category_.json b/docs_old/cli-tools/_category_.json deleted file mode 100644 index 43bdb336..00000000 --- a/docs_old/cli-tools/_category_.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "label": "Tools", - "position": 5, - "link": { - "type": "generated-index", - "description": "Tooling information for the 0L Network" - } -} \ No newline at end of file diff --git a/docs_old/cli-tools/archived/tower_archived.todo b/docs_old/cli-tools/archived/tower_archived.todo deleted file mode 100644 index 368586a6..00000000 --- a/docs_old/cli-tools/archived/tower_archived.todo +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: "Tower" -id: "index" -hidden: false ---- - -# What is Tower - -Tower is the verifiable delay function (VDF) proof-of-work system 0L used to bootstrap and mint all the coins up to V7. Users mine up to a certain maximum amount of proofs per epoch which are submitted into the Blockchain. For more info about Delay Towers, please follow our series of [Blog post](https://0l.network/2021/11/01/) - -## How to use Tower in 0L Network? - -A CLI tool with all needed capabilities is provided. It allows to do things such as mining, verifying, submitting proofs, etc. - -### Tower CLI -The `tower` tool is a command line interface (CLI) for managing tower proofs in the 0L network. - -- [Use Tower CLI](tower/use-tower-cli) diff --git a/docs_old/cli-tools/archived/use_tower_cli_archived.todo b/docs_old/cli-tools/archived/use_tower_cli_archived.todo deleted file mode 100644 index d492c57e..00000000 --- a/docs_old/cli-tools/archived/use_tower_cli_archived.todo +++ /dev/null @@ -1,70 +0,0 @@ ---- -title: "Use the Tower CLI" -id: "use-tower-cli" ---- -## Tower CLI commands and options -```bash -libra tower --help -``` -Output: -``` -clap struct entry point for the tower cli - -Usage: libra tower [OPTIONS] - -Commands: - backlog - start - once - zero - help Print this message or the help of the given subcommand(s) - -Options: - -l, --local-mode - If the node is offline and tower needs to run in local mode without querying chain - -c, --config-file - The optional path to an alternate path besides $HOME/.0L - -p, --profile - nickname of the profile to use, if there is more than one. Defaults to first - -t, --test-private-key - optional, private key of the account. Otherwise this will prompt for mnemonic. Warning: intended for testing - -h, --help - Print help - -V, --version - Print version -``` - -## Configuration -If you don't already a valid `libra.yml` configuration file under path `~/.libra`, you may generate a new one with the following command (mnemonic needed): -```bash -libra config init -``` -Alternatively, the configuration folder can also be overwritten by: -```bash -libra config init --path -``` - -## Mining (Production Mode) -If you wish to create the genesis proof AKA proof zero of the configured account, execute the command: -```bash -libra tower zero -``` -If everything went find, you should be able to see the file `proof_0.json` under `/vdf_proofs_/` -Now let us generate the proof #n 1: -```bash -libra tower once -``` -The above command will generate only one proof, which is good for testing purposes, but in production you may want to keep generating proofs automatically. This can be achieved with the following command: -```bash -libra tower start -``` -The previous command will keep generating proofs and submit them automatically, but what if for some reason you wish to submit them manually? We got you: -```bash -libra-tower backlog -``` - -## Mining (Testing Mode) -For testing purposes is not feasible to wait too long just to have a generated proof, therefore it's possible to generate proofs in 1 sec. Such can be achieved using any of the above mining commands, we just need environment variable instructing to generate a proof a testing mode. Eg: -```bash -MODE_0L=TESTING libra tower zero -``` diff --git a/docs_old/cli-tools/config.todo b/docs_old/cli-tools/config.todo deleted file mode 100644 index 0ab08809..00000000 --- a/docs_old/cli-tools/config.todo +++ /dev/null @@ -1,65 +0,0 @@ ---- -sidebar_position: 3 -description: 'Initialize configs' ---- - - -# Config - -## Description -The `ConfigCli` tool is a command-line utility within the Libra Framework designed to facilitate the generation and management of configuration files for various components of the 0L Network. Its primary function is to create and modify the `libra.yaml` configuration file, which is essential for the operation of CLI tools like `txs`, `tower`, and others within the ecosystem. - -The tool provides several subcommands to handle different aspects of configuration, from initializing new configurations to adjusting existing ones, as well as specialized options for validators and fullnodes. - -## How to Use the Config Tool -`config` is invoked from the command line and requires a subcommand to specify the action to be taken. It can operate on a global configuration directory or a specified path, and it can manage different network profiles for various deployment environments like MAINNET, TESTNET, and DEVNET. - -### Subcommands - -#### Init -- **Purpose**: Initializes the `libra.yaml` configuration file with options for various CLI tools. -- **Syntax**: `libra config init [OPTIONS]` -- **Options**: - - `--force-address
`: Force a specific account address instead of deriving from mnemonic. - - `--force-authkey `: Force a specific authentication key, requires `--force_address`. - - `--test-private_key `: Use a private key for initialization (intended for testing). - - `--playlist-url `: URL for a network playlist to load default nodes from. -- **Example**: - ``` - libra config init --force-address 0x1 --force-authkey "0x..." --test-private-key "0x123..." - ``` - -#### Fix -- **Purpose**: Attempts to fix or adjust the `libra.yaml` file with various options. -- **Syntax**: `libra config fix [OPTIONS]` -- **Options**: - - `--address`: Reset the address from mnemonic and look up the chain for the actual address. - - `--remove-profile `: Remove the profile with the specified name. - - `--force-url `: Force overwrite all URLs in the current network profile to this URL. -- **Example**: - ``` - libra config fix --address --remove-profile "test_profile" - ``` - -#### ValidatorInit -- **Purpose**: Generates the validators' configuration file. -- **Syntax**: `libra config validator-init [OPTIONS]` -- **Options**: - - `--check`: Check the files generated. -- **Example**: - ``` - libra config validator-init --check - ``` - -#### FullnodeInit -- **Purpose**: Generates a fullnode directory and adds `fullnode.yaml` from the template. -- **Syntax**: `libra config fullnode-init [OPTIONS]` -- **Options**: - - `--home-path `: Path to libra config and data files, defaults to `$HOME/.libra`. -- **Example**: - ``` - libra config fullnode-init --home_path "/path/to/fullnode" - ``` - -### Note -When using the `ConfigCli` tool, it is important to be aware of the network and profile context in which you're operating. Make sure to back up your existing configurations before making changes, especially in a production environment. diff --git a/docs_old/cli-tools/first_steps.todo b/docs_old/cli-tools/first_steps.todo deleted file mode 100644 index 6cd110d0..00000000 --- a/docs_old/cli-tools/first_steps.todo +++ /dev/null @@ -1,223 +0,0 @@ ---- -title: First Steps -sidebar_position: 4 -slug: / -tags: - - Getting started ---- - -# First Steps - Common Useful Operations - -## Introduction - -This guide is designed to help you set up your development environment and introduce you to some common operations that are useful for interacting with the Libra blockchain. Whether you're a validator, core developer, or simply curious about Libra, this document will walk you through the initial steps to get you started ๐Ÿš€ - -## Setup Environment Quick Start - -### Clone the Repository - -First, let's clone the libra-framework repository to your local machine. This contains all the necessary code and tools to work with the Libra blockchain. We recommend using a tmux session to keep your setup process manageable, especially if you're connecting over SSH. - -```bash -# Start or attach to a tmux session -tmux a -cd ~ -# Clone the libra-framework repository -git clone https://github.com/0LNetworkCommunity/libra-framework -cd ~/libra-framework -``` - -### Prepare Your Instance - -Depending on your role (validator, core developer, Move developer, or CI), you will need to install different sets of tools: - -```bash -# View all development setup options -bash ./util/dev_setup.sh -h -# Install build tools for validators -bash ./util/dev_setup.sh -t - -# Install build tools and Postgres for core developers -bash ./util/dev_setup.sh -tP - -# Install Move Prover tools for Move developers -bash ./util/dev_setup.sh -ty - -# Setup for CI with no user input required -bash ./util/dev_setup.sh -tb -``` - -:::info - -Once you have installed the required set of tools, make sure your shell has the access to the cargo binary. -You can test this with: - -`` -cargo --version -`` - -If the cargo binary is not accessible from your shell, you may want to source your shell file. - -For e.g., For a bash shell you can run: - -`` -source "$HOME/.cargo/env" -`` - -::: - -# Build the project -``` -cargo build --release -``` - -### Finalizing Setup - -After building the project, you'll have the Libra framework binaries ready. To make these binaries easily accessible, add them to your PATH: - -```bash -# Copy binaries to your Cargo bin directory -sudo cp -f ./target/release/libra* ~/.cargo/bin/ -``` - -Well done! ๐Ÿ‘ You now have a fully operational node running the 0L Libra framework. - -## Basic Query Operations - -### Check Account Balance - -To check the balance of an account, use the following command: - -```bash -libra query balance ADDRESS -``` - -### Check Your Vouches - -For validators, to check for vouches: - -```bash -libra query resource --resource-path-string 0x1::vouch::MyVouches ADDRESS -``` - -### Get Total Supply - -To view the total supply of Libra coins: - -```bash -libra query view --function-id "0x1::gas_coin::supply" -``` - -## Node Operations - -### Send Coins - -To transfer coins to another account: - -```bash -libra txs transfer --to-account DESTINATION_ADDRESS --amount AMOUNT -``` - -## Validator-Specific Operations - -These operations are exclusively for validators. - -### Vouch for an Account - -To vouch for another account: - -`libra txs validator vouch --vouch-for ADDRESS` - -### Query for Vouches - -To query for vouches you have received: - -```bash -libra query view --function-id 0x1::vouch::true_friends --args ADDRESS -``` - -### Bid for Position - -To bid for a validator position: - -```bash -libra txs validator pof --bid-pct PERCENT_YOU_PAY --expiry EPOCH_NUMBER_WHEN_BID_EXPIRES -# Example -libra txs validator pof --bid-pct 0.9 --expiry 999 -``` - -### Un-jail Account - -To un-jail an account (note: self-unjail is not possible): - -```bash -libra txs validator jail --unjail-acct ADDRESS -``` - -## Monitoring Your Node - -### Status Page - -To set up a local status page for monitoring: - -```bash -git clone https://github.com/0LNetworkCommunity/status.git -cd status -yarn -yarn dev -# Visit http://localhost:5173 to view the status page -``` - -### Grafana Local Setup - -Here's a quick guide to setting up Grafana locally on your PC. If you'd like to go into more detail, don't hesitate to consult the [official documentation](https://grafana.com/docs/grafana/latest/). - -#### Prerequisites - -A server or local machine with a 0L node already set up and running. -Docker installed on your machine (recommended for simplicity). - -#### Install Grafana Using Docker - -Pull the Grafana Docker image by running the following command in your terminal: - -```bash -docker pull grafana/grafana -``` - -Run the Grafana container with the following command: - -```bash -docker run -d -p 3000:3000 grafana/grafana -``` - -This command runs Grafana in a Docker container and maps port 3000 of the container to port 3000 on your host machine, allowing you to access Grafana at http://localhost:3000. - -#### Access Grafana - -Open a web browser and navigate to http://localhost:3000. -Log in with the default credentials (username: admin, password: admin). You will be prompted to change the password. - -#### Connect Grafana to Your 0L Node - -To monitor your 0L node, you need to connect Grafana to the node's data source. If your 0L node exposes metrics via an HTTP API or a compatible database, follow these general steps: - -#### Add a Data Source in Grafana: - -- Go to the Grafana dashboard -- Navigate to "Configuration" > "Data Sources". -- Click "Add data source" and select the type that matches your 0L node's data output (e.g., Prometheus, MySQL, etc.). -- Configure the Data Source with the URL and any authentication details required to access your 0L node's metrics. - -Save and Test to ensure Grafana can retrieve data successfully. - -#### Create Dashboards - -Once Grafana is connected to your 0L node's data source, you can create dashboards to visualize the data: - -- Navigate to "Create" > "Dashboard". -- Add panels and select the metrics you wish to monitor. -- Configure the panel settings, such as the query, visualization type, and panel title. -- Repeat these steps to add more panels as needed, customizing your dashboard to display the 0L node metrics most relevant to you. - -Here we go! You now have Grafana set up to monitor your 0L (Libra) node. You can extend this setup by exploring more Grafana features, such as alerts and more advanced dashboard configurations, to suit your monitoring needs. diff --git a/docs_old/cli-tools/genesis.todo b/docs_old/cli-tools/genesis.todo deleted file mode 100644 index 88c0339a..00000000 --- a/docs_old/cli-tools/genesis.todo +++ /dev/null @@ -1,69 +0,0 @@ ---- -sidebar_position: 3 -description: 'Start the 0L Network' ---- - -# Genesis - - -## Description -The Genesis tool within the Libra Framework serves as a foundational utility for initializing and configuring the state of the 0L blockchain. It facilitates the creation of the genesis block โ€” the very first block in the blockchain โ€” and sets up various initial parameters and configurations for the network. - -This tool is crucial for setting up a new 0L blockchain network or resetting an existing network to a new initial state. It's particularly useful for testnets, development environments, and initializing mainnet configurations. - -### Important Note -This package is built separately from the main Libra CLI tool. As per its `Cargo.toml`, it is compiled as `libra-genesis-tools`. To build the tool, run the following command: -``` -cargo build --package libra-genesis-tools -``` - -## How to Use the CLI Tool -The Genesis tool CLI offers a user-friendly command-line interface for initiating and configuring the Libra blockchain. It's centered around three primary commands: - -> You need a Github Auth Token and the cli searches in `~/.libra/github_token.txt` for it but you can also specify a path. More info [here](https://docs.github.com/rest/repos/contents#create-or-update-file-contents) - -### Genesis -- **Purpose**: Initializes the genesis block with specified configurations. -- **Key Features**: - - GitHub integration for managing configurations and data. - - Supply settings for initial token distribution and asset management. -- **Syntax**: `libra-genesis-tools genesis --token-github --org-github --name-github [--local-framework] [--json-legacy ] [--target-supply ] [--target-future-uses ] [--years-escrow ] [--map-dd-to-slow ]` -- **Function**: Initializes the genesis block using GitHub-based configurations. -- **Example**: - ``` - cargo r -- genesis --org-github OLNetworkCommunity \ - --name-github genesis-repo \ - --local-framework \ - --json-legacy ./tests/fixtures/recovery.json \ - --target-supply 10000000 \ - --target-future-uses 0.7 \ - --years-escrow 7 \ - --map-dd-to-slow 3A6C51A0B786D644590E8A21591FA8E2 \ - --map-dd-to-slow 2B0E8325DEA5BE93D856CFDE2D0CBA12 - ``` - -### Register -- **Purpose**: Manages registration processes, focusing mainly on GitHub interactions. -- **Key Features**: - - Facilitates GitHub-based configurations and data retrieval for the blockchain setup. -- **Syntax**: `libra-genesis-tools register --token-github --org_github --name_github ` -- **Function**: Registers GitHub repositories and settings for blockchain setup. -- **Example**: - ``` - libra-genesis-tools register --org_github libra --name_github registry - ``` - -### Wizard -- **Purpose**: Provides a guided, interactive setup process for initializing the genesis block and related configurations. -- **Key Features**: - - User-friendly interface for blockchain configuration. - - Combines GitHub integration and supply settings in an interactive setup. -- **Syntax**: `libra-genesis-tools wizard --token-github --org_github --name_github --local_framework` -- **Function**: Guides the user through an interactive process for setting up the genesis block and related configurations. -- **Example**: - ``` - libra-genesis-tools wizard --org_github libra --name_github setup --local_framework - ``` - ---- - diff --git a/docs_old/cli-tools/getting_started.todo b/docs_old/cli-tools/getting_started.todo deleted file mode 100644 index 40dc79e8..00000000 --- a/docs_old/cli-tools/getting_started.todo +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: "Getting Started" -sidebar_position: 1 -description: 'quick start with libra cli' ---- - -# Getting Started ---- - -## About Libra Tool Design -The tools are intended to be minimalist, yet modular. Upstream vendors have sophisticated and complex tooling. This is usually unwieldy for the profile of typical 0L users. - -### The Customer -If you have a typical end-user use case, Carpe will likely be all you need. -These tools are for users which are engaged in more admin level operations on the network: configuring and querying contracts. - -For that user the cli tools here will like have sufficient features: query, transact, run node. - -Similarly if you are a Move dev, similarly the most common features are covered: testing, verifying, compiling, deploying. - -### Bring your own tool -If you have needs that aren't met with these tools, all of them are also exported as libraries. Meaning: they are architected so that they are easy to extend. - -#### Start a new minimal Rust crate -With a simple Rust project, that uses Clap as a CLI scaffold, you can import all of the CLI types, whole or in part. This means you can extend the existing methods (by creating a `trait` extension in your own tool). - -Additionally the most relevant vendor SDK types are re-exported by `libra-types`. So you should be able to take advantage of much of the Move resource parsing (e.g converting account addresses from API calls to structs); - -### Build -:::note -This targets an ubuntu 22.04 build. You may also need to create an account. Do it [here](./wallet.md) -::: - -``` -# We suggest you run the following in a tmux session from your user home directory -tmux a -cd ~ - -# Checkout the source -git clone https://github.com/0LNetworkCommunity/libra-framework - -# Install dependencies and Rust lang -cd ~/libra-framework -bash ./util/dev_setup.sh -t - -# build and install the binary -cd ~/libra-framework -cargo build --release -p libra - -# Make the release path global and persistent -sudo cp -f ~/libra-framework/target/release/libra* ~/.cargo/bin/ - -# Initialize your expanded PATH -source ~/.bashrc - -# Check libra execution and version -libra -v -``` diff --git a/docs_old/cli-tools/move/index.todo b/docs_old/cli-tools/move/index.todo deleted file mode 100644 index 8e19c41c..00000000 --- a/docs_old/cli-tools/move/index.todo +++ /dev/null @@ -1,227 +0,0 @@ ---- -title: "Move" -id: "index" -hidden: true -description: 'Develop with the Move Tool' ---- -:::danger WIP -The Move tool is a Diem wrapper that needs some TLC.... Bounties are available through the Tool Scrubbers Guild if you would like to contribute! -::: - -# Move - -> The Move CLI is a vendor package and original documentation can be found [here](https://github.com/0LNetworkCommunity/diem/tree/release/third_party/move/tools/move-cli) - -## Description -The Move command-line interface (Move CLI) is a tool that provides an easy way to interact with Move, to experiment -with writing and running Move code, and to experiment with developing new tools useful -for Move development. To reflect this, the Move CLI commands are grouped into -three main subcommands: -* **package commands**: are commands to create, compile, and test Move packages, as well as perform other operations related to packages. These do not rely on a Move Adapter implementation nor an implementation of storage. -* **sandbox commands**: are commands that allow you to write Move modules and scripts, write and run scripts and tests, and view the resulting state of execution in a local sandboxed environment. -* **experimental commands**: are experimental commands that are currently in development. - -Every Move CLI command, with the exception of `package create`, is expected to be run within the context of a [Move package](https://move-language.github.io/move/packages.html). - -### Compliling -The `libra` CLI can be used to compile a Move package locally. -The below example uses the `HelloBlockchain` in [fixtures](https://github.com/0LNetworkCommunity/libra-framework/tree/main/tools/txs/tests/fixtures/test_publish). - -:::note -You will first need to uncomment `[addresses]` in `Move.toml` and add your address you will be using -::: -``` -[package] -name = 'test_publish' -version = '1.0.0' - -#[addresses] -#this_address='0xd1281de242839fc939745996882c5fc2' - -[dependencies.DiemFramework] -git = 'https://github.com/0LNetworkCommunity/diem.git' -rev = 'release' -subdir = 'diem-move/framework/diem-framework' -``` - - - -```bash -$ libra move compile --package-dir /libra-framework/tools/txs/tests/fixtures/test_publish -``` - -The above command will generate the below terminal output: -```bash -Compiling, may take a little while to download git dependencies... -UPDATING GIT DEPENDENCY https://github.com/0LNetworkCommunity/diem.git -INCLUDING DEPENDENCY DiemFramework -INCLUDING DEPENDENCY DiemStdlib -INCLUDING DEPENDENCY MoveStdlib -BUILDING test_publish -``` - -### Compiling and unit testing Move - -The `libra` CLI can also be used to compile and run unit tests locally. -In this example, we'll use the `HelloBlockchain` in [fixtures](https://github.com/0LNetworkCommunity/libra-framework/tree/main/tools/txs/tests/fixtures/test_publish). - -```bash -$ libra move test --package-dir /libra-framework/tools/txs/tests/fixtures/test_publish -``` -The above command will generate the following terminal output: -```bash -INCLUDING DEPENDENCY DiemFramework -INCLUDING DEPENDENCY DiemStdlib -INCLUDING DEPENDENCY MoveStdlib -BUILDING test_publish -Running Move unit tests -Test result: OK. Total tests: 0; passed: 0; failed: 0 -``` -### Generating test coverage details for Move -The `libra` CLI can be used to analyze and improve the testing of your Move modules. To use this feature: -1. In your `libra` source checkout, navigate to the `libra-framework/framework/move-stdlib` directory. -2. Execute the command: - ```bash - $ libra move test --coverage - ``` -3. Receive results in standard output containing the result for each test case followed by a basic coverage summary resembling: - ```bash - BUILDING MoveStdlib -Running Move unit tests -[ PASS ] 0x1::vector_tests::append_empties_is_empty -[ PASS ] 0x1::option_tests::borrow_mut_none -[ PASS ] 0x1::fixed_point32_tests::ceil_can_round_up_correctly -[ PASS ] 0x1::features::test_change_feature_txn -[ PASS ] 0x1::bcs_tests::bcs_bool -[ PASS ] 0x1::bit_vector_tests::empty_bitvector -[ PASS ] 0x1::option_tests::borrow_mut_some -Test result: OK. Total tests: 149; passed: 149; failed: 0 -+-------------------------+ -| Move Coverage Summary | -+-------------------------+ -Module 0000000000000000000000000000000000000000000000000000000000000001::bcs ->>> % Module coverage: NaN -Module 0000000000000000000000000000000000000000000000000000000000000001::fixed_point32 ->>> % Module coverage: 100.00 -Module 0000000000000000000000000000000000000000000000000000000000000001::hash ->>> % Module coverage: NaN -Module 0000000000000000000000000000000000000000000000000000000000000001::vector ->>> % Module coverage: 92.19 -Module 0000000000000000000000000000000000000000000000000000000000000001::error ->>> % Module coverage: 0.00 -Module 0000000000000000000000000000000000000000000000000000000000000001::acl ->>> % Module coverage: 0.00 -Module 0000000000000000000000000000000000000000000000000000000000000001::bit_vector ->>> % Module coverage: 97.32 -Module 0000000000000000000000000000000000000000000000000000000000000001::signer ->>> % Module coverage: 100.00 -Module 0000000000000000000000000000000000000000000000000000000000000001::features ->>> % Module coverage: 69.41 -Module 0000000000000000000000000000000000000000000000000000000000000001::option ->>> % Module coverage: 100.00 -Module 0000000000000000000000000000000000000000000000000000000000000001::string ->>> % Module coverage: 81.82 -+-------------------------+ -| % Move Coverage: 83.50 | -+-------------------------+ -Please use `libra move coverage -h` for more detailed test coverage of this package - ``` - -4. Optionally, narrow down your test runs and results to a specific package name with the `--filter` option, like so: - ```bash - $ libra move test --coverage --filter vector - ``` - - With results like: - ``` - BUILDING MoveStdlib - Running Move unit tests - [ PASS ] 0x1::bit_vector_tests::empty_bitvector - [ PASS ] 0x1::vector_tests::append_empties_is_empty - [ PASS ] 0x1::bit_vector_tests::index_bit_out_of_bounds - [ PASS ] 0x1::vector_tests::append_respects_order_empty_lhs - ``` - -5. Find failures and iteratively improve your testing and running these commands to eliminate gaps in your testing coverage. - -### Proving Move -:::note -This functionality is currently unavailable... Check back soon -::: - -### Profiling gas usage -:::note -This functionality is currently unavailable... Check back soon -::: -### Debugging and printing stack trace - -In this example, we will use `DebugDemo` in [debug-move-example](https://github.com/aptos-labs/aptos-core/tree/main/crates/aptos/debug-move-example). - -Now, you can use `debug::print` and `debug::print_stack_trace` in your [DebugDemo Move file](https://github.com/aptos-labs/aptos-core/tree/main/crates/aptos/debug-move-example/sources/DebugDemo.move). - -> NOTE: This command does not work but gives an example for coding best practices - -```bash -$ libra move test --package-dir https://github.com/aptos-labs/aptos-core/tree/main/crates/aptos/debug-move-example -``` - -The command will generate the following output: -```bash -Running Move unit tests -[debug] 0000000000000000000000000000000000000000000000000000000000000001 -Call Stack: - [0] 0000000000000000000000000000000000000000000000000000000000000001::Message::sender_can_set_message - - Code: - [4] CallGeneric(0) - [5] MoveLoc(0) - [6] LdConst(0) - > [7] Call(1) - [8] Ret - - Locals: - [0] - - [1] 0000000000000000000000000000000000000000000000000000000000000001 - - -Operand Stack: -``` - - -### Publishing a Move package with a named address -:::note -Named Addresses is currently unavailable... Check back soon -::: -:::tip -As an open source project, the source code as well as compiled code published to the 0L Network is inherently open by default. This means code you upload may be downloaded from on-chain data. Even without source access, it is possible to regenerate Move source from Move bytecode. To disable source access, publish with the `--included-artifacts none` argument, like so: - -``` -libra move publish --included-artifacts none -``` -::: - -:::tip -When publishing Move modules, if multiple modules are in one package, then all the modules in this package must have the same account. If they have different accounts, then the publishing will fail at the transaction level. -::: - -### Running a Move function -:::note -The `move run` feature is currently not available but we have a work around for interacting with move functions. View a full description [here](../txs/generate-transaction.md) -::: - - -```bash -$ libra txs generate-transaction --function-id 0xd1281de242839fc939745996882c5fc2::message::set_message --args '42' -``` - - -### View functions -:::note -The `libra move view` feature is currently not available but we have a couple of workarounds for viewing move functions and values. View a full description [here](../getting-started.md) -::: -```bash -$ libra query move-value --account 0xd1281de242839fc939745996882c5fc2 --module-name message --struct-name MessageHolder --key-name message -``` -```bash -$ libra query view --function-id 0x1::reconfiguration::get_current_epoch -``` diff --git a/docs_old/cli-tools/node/index.todo b/docs_old/cli-tools/node/index.todo deleted file mode 100644 index 6cb280e1..00000000 --- a/docs_old/cli-tools/node/index.todo +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Node" -id: "index" -hidden: false -description: 'Operate a Node' ---- - -# Libra Node - -## Description -The Libra Node application facilitates the operation of a validator or full node within the 0L Network. This application is pivotal for maintaining the network's integrity, processing transactions, and participating in consensus. - -### Node Configuration -The 0L Node can function either as a validator node, participating in the consensus and validation of transactions, or as a full node, which replicates the blockchain data and provides query access to clients. Configuration of a node, specifying its role and behavior, is done via a YAML configuration file. - -## How to Use the Node Command -The `libra node` command is used to start a 0L validator or full node. The command-line interface provides options for specifying the configuration file necessary for launching the node. - -### Starting a Node -- **Syntax**: `libra node --config-path ` -- **Function**: Starts a 0L validator or full node using the specified configuration file. -- **Parameters**: - - `-c, --config-path `: Filepath to the validator or fullnode YAML configuration file. -- **Example**: - - To start a 0L node with a specific configuration file: - ``` - libra node --config-path /path/to/node_config.yaml - ``` - -This command initializes and runs a 0L node using the configuration specified in `/path/to/node_config.yaml`, setting up the node as either a validator or a full node based on the configuration details. - ---- \ No newline at end of file diff --git a/docs_old/cli-tools/query/_category_.json b/docs_old/cli-tools/query/_category_.json deleted file mode 100644 index 84ec8ae5..00000000 --- a/docs_old/cli-tools/query/_category_.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "label": "Query", - "position": 3, - "link": { - "type": "generated-index", - "description": "Get information about the chain" - } -} \ No newline at end of file diff --git a/docs_old/cli-tools/query/balance.todo b/docs_old/cli-tools/query/balance.todo deleted file mode 100644 index 250a9cf3..00000000 --- a/docs_old/cli-tools/query/balance.todo +++ /dev/null @@ -1,34 +0,0 @@ ---- -sidebar_label: 'Balance' -sidebar_position: 2 -description: 'Query for account balance' ---- -# Balance - ---- - -## Usage - -``` -$> libra query balance --account ADDRESS -``` - -Print out will be of the format: -``` -{ - "unlocked": 7151600.786542, - "total": 7151600.786542 -} -``` - -### Unlocked ---- - -The unlocked balance is the amount of funds that are available for the account to use. This is the amount that can be used to send transactions, or to delegate to a validator. - -### Total ---- - -The total balance is the amount of funds that are available for the account to use, plus the amount of funds that are locked up in the account. The total balance is the sum of the unlocked balance and the locked balance. - -> Unlocked != total indicates that the account recieved funds that are related to a specific contribution to the network, such as a validator, or a worker, and that these funds are locked and are being released by the daily unlock rate (`SLOW_WALLET_EPOCH_DRIP`) diff --git a/docs_old/cli-tools/query/epoch.todo b/docs_old/cli-tools/query/epoch.todo deleted file mode 100644 index ce91c213..00000000 --- a/docs_old/cli-tools/query/epoch.todo +++ /dev/null @@ -1,21 +0,0 @@ ---- -sidebar_label: 'Epoch' -sidebar_position: 5 -description: 'Retrieve current network epoch number' ---- -# Epoch - ---- - -## Usage - -``` -$> libra query epoch -``` - -Print out will be of the format: -``` -{ - "epoch": 299 -} -``` diff --git a/docs_old/cli-tools/query/getting_started.todo b/docs_old/cli-tools/query/getting_started.todo deleted file mode 100644 index f1372f88..00000000 --- a/docs_old/cli-tools/query/getting_started.todo +++ /dev/null @@ -1,41 +0,0 @@ ---- -sidebar_label: 'Getting Started' -sidebar_position: 1 -description: 'Learn how to query the blockchain for views and resources' ---- -# Getting Started - -### The query tool provides a command line interface to retrieve information about the blockchain. From an Account perspective, and from the global network state. ---- - -## Usage - -> It is recommended to pipe the output of the query tool to `jq` or another json parser for pretty printing. -The usage then would be `libra query | jq` - -``` -$> libra query -Query the blockchain for views and resources - -Usage: libra query - -Commands: - balance Account balance - tower User's Tower state - val-config A validator's on-chain configuration - epoch Epoch and waypoint - resource All account resources - view Execute a View function on-chain - lookup-address Looks up the address of an account given an auth key. The authkey diverges from the address after a key rotation - sync-delay How far behind the local is from the upstream nodes - help Print this message or the help of the given subcommand(s) - -Options: - -h, --help Print help - -V, --version Print version -``` - -:::danger WIP -Not implemented yet: -`sync-delay` -::: diff --git a/docs_old/cli-tools/query/resources.todo b/docs_old/cli-tools/query/resources.todo deleted file mode 100644 index 0b02cbc5..00000000 --- a/docs_old/cli-tools/query/resources.todo +++ /dev/null @@ -1,53 +0,0 @@ ---- -sidebar_label: 'Resources' -sidebar_position: 6 -description: 'Retrieve an account resources' ---- - -# Resources ---- - -## Description - -In the Diem blockchain and the Move programming language, a resource is a general-purpose tool for encapsulating and managing state. A resource can represent any kind of state that needs to be associated with an account and benefits from the Move language's guarantees, such as data integrity, type safety, and controlled access patterns. - -For example, a resource could represent: - -- User identities, profiles, or permissions. -- Contracts with specific terms and conditions. -- Ownership or participation in a system, like voting rights. -- Token assets -- Non-fungible assets like collectibles, game items, or digital media. -- Domain-specific state, such as staking information, loyalty points, or system configuration. - -Resources are powerful abstractions for state management, particularly for creating a system of digital assets that require strict rules around their creation, duplication, transfer, and destruction. The ability to enforce invariants through the type system makes them well-suited for a wide range of applications beyond just tokens. - -The query tool provides an easy interface to query resources - ---- - -## Usage - -``` -libra query resource --account ADDRESS --resource-path-string RESOURCE_PATH_STRING -``` - -Example: -``` -libra query resource --account 0x2865f3332b998ac267fabcf3801ef089 --resource-path-string 0x1::ancestry::Ancestry -``` - -:::note What can be queried? - -`struct` resources with `has key` (stored in global storage) can be queried. - -::: - -:::tip How to figure out the --resource-path-string? - -The `--resource-path-string` is made of the `address` of the resource, the `name` of the module, and the `name` of the resource itself. -In the above example, `0x1` is the address of the resource, `ancestry` is the name of the module, and `Ancestry` is the name of the resource. - -::: - - diff --git a/docs_old/cli-tools/query/val_config.todo b/docs_old/cli-tools/query/val_config.todo deleted file mode 100644 index 32b80deb..00000000 --- a/docs_old/cli-tools/query/val_config.todo +++ /dev/null @@ -1,38 +0,0 @@ ---- -sidebar_label: "Validator config" -sidebar_position: 4 -description: "Get a validator's onchain configuration" ---- - - -# Validator Config - ---- - -## Description - -Get a validator's on-chain configuration - -## Usage - -``` -libra query val-config --account ACCOUNT -``` - -## Example - - -``` -./libra query val-config --account 0xd1231de242839fc939745996882c5abc - -{ - "consensus_public_key": "0xabcf4b268d6aac24e4ca47f08bc12cb8aead75d2f495982c736dce340edd8a5bcba2d052e23f135e0ccc13136be16abc", - "validator_network_addresses": [ - "/ip4/31.82.100.83/tcp/6180/noise-ik/0xabccab5f2ecb29bdb4a9eac4dd4576feacefe4ec74ab7ef65d472bbb44618abc/handshake/0" - ], - "fullnode_network_addresses": [ - "/ip4/32.56.100.14/tcp/6180/noise-ik/0xabccab5f2ecb29bdb4a9efe1dd4576feacabc4ec74ab7ef65d472bbb44618abc/handshake/0" - ], - "validator_index": 2 -} -``` diff --git a/docs_old/cli-tools/query/view.todo b/docs_old/cli-tools/query/view.todo deleted file mode 100644 index aaf867fe..00000000 --- a/docs_old/cli-tools/query/view.todo +++ /dev/null @@ -1,105 +0,0 @@ ---- -sidebar_label: 'View' -sidebar_position: 7 -description: 'Access pre-defined view methods' ---- - -# View ---- - -## Description - -Throughout the codebase, there are many public methods with the `#[view]` attribute. These methods are meant to retrieve various states and network values that are not related to a specific account (or at least not nessecerily). - -The `query view` command allows you to invoke those methods from the command line, including the passing of required params when needed. - ---- - -## Usage - -``` -libra query view [OPTIONS] --function-id - -Options: - -f, --function-id Function identifier has the form
:::: - - Example: - 0x1::coin::balance - - -t, --type-args Type arguments separated by commas - - Example: - 'u8, u16, u32, u64, u128, u256, bool, address, vector, signer' - - -a, --args Function arguments separated by commas - - Example: - '0x1, true, 12, 24_u8, x"123456"' - - -h, --help Print help - -``` - -## Examples - -:::note View invocation format -Note that the examples are querying the canonical system resource at `0x1`, however, other view methods can be queried in the same way, following the `RESOURCE_ADDRESS::MODULE_NAME::FUNCTION_NAME` pattern -::: - - -``` -# Get the total suppply of the GAS coin -# This will call the method with the following signature -# -# #[view] -# public fun supply(): Option acquires CoinInfo {...} - -libra query view --function-id 0x1::gas_coin::supply - -{ - "body": [ - "99999999355972010" - ] -} -``` - -``` -# Get validators votes for network upgrade proposal #2. First `Yes` vote count, then `No` vote count - -# This will call the method with the following signature (note the expected `proposal_id` argument that is passed with the --args flag) -# #[view] -# public fun get_votes(proposal_id: u64) {...} - -libra query view --function-id 0x1::diem_governance::get_votes --args 2 - -{ - "body": [ - "10", - "0" - ] -} -``` - -``` -# Get the list of validators that vouched for an account - -# This will call the method with the following signature (note the expected `proposal_id` argument that is passed with the --args flag) -# #[view] -# public fun all_vouchers(val: address): vector
acquires MyVouches {...} - -libra query view --function-id 0x1::vouch::all_vouchers --args 0xd1281de242839fc939745996882c5fc2 - -{ - "body": [ - [ - "0xebbd5fb7042a7021dd71e3f6bddd55f3", - "0xd3ad1f9682d57d562efd23924aa8aaaf4c0410df5b1a9ff3e4b1efa04273f5b9", - "0x32f24e0488a4e189d38fccd1f2a94b53", - "0x3d3763dd90531da4fa264b4b76c9c5a76435c9b3eed2699b1f79bda28d23c42e", - "0x304a03c0b4acdfdce54bfaf39d4e0448", - "0xd67f3ff22bd719eb5be2df6577c9b42d", - "0xc208c09ecb52d626ef037c2011ba2d7b18f999eee5be54ac8161627613500c93" - ] - ] -} -``` diff --git a/docs_old/cli-tools/txs/_category_.json b/docs_old/cli-tools/txs/_category_.json deleted file mode 100644 index 9a3eed41..00000000 --- a/docs_old/cli-tools/txs/_category_.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "label": "Txs", - "position": 2, - "link": { - "type": "generated-index", - "description": "Send Transactions on the 0L network" - } - } \ No newline at end of file diff --git a/docs_old/cli-tools/txs/generate_transaction.todo b/docs_old/cli-tools/txs/generate_transaction.todo deleted file mode 100644 index 76f86524..00000000 --- a/docs_old/cli-tools/txs/generate_transaction.todo +++ /dev/null @@ -1,22 +0,0 @@ ---- -sidebar_position: 3 -description: 'Interact with Move Code' ---- - -# Txs - Generate Transaction - - - -## Description -Generates a transaction to execute an Entry function on the 0L Network. This command is used to create transactions that call Entry functions of smart contracts deployed on-chain, facilitating direct interaction with public smart contract code. - -### Generate-Transaction Command -- **Function**: Creates a transaction for interacting with public smart contract functions on the 0L Network. -- **Syntax**: `libra txs generate-transaction --function-id [OPTIONS]` -- **Parameters**: - - `--function-id `: The fully qualified identifier of the smart contract function to be invoked. This identifier includes the module address, module name, and function name. -- **Example**: - ``` - libra txs generate-transaction --function-id 0xd1281de242839fc939745996882c5fc2::message::set_message --args '42' - ``` - This command generates a transaction to invoke the `set_message` function within the `message` module located at address `0xd1281de242839fc939745996882c5fc2`, passing '42' as the argument. diff --git a/docs_old/cli-tools/txs/publish.todo b/docs_old/cli-tools/txs/publish.todo deleted file mode 100644 index 8ce1ab6e..00000000 --- a/docs_old/cli-tools/txs/publish.todo +++ /dev/null @@ -1,64 +0,0 @@ ---- -sidebar_position: 3 -description: 'Publish Move Modules' ---- - -# Txs - Publish - - - -## Description -The `txs` tool is instrumental in sending Package Publish transactions, enabling developers to deploy their smart contracts on the Libra blockchain. An example Move package, used in internal "smoke tests", can be found under `./tests/fixtures/test_publish`. - -### Publishing Smart Contracts - -#### Compiling -Before publishing, it is advised to test and compile the code. However, the `txs publish` command will automatically compile the package as part of the submission process, making pre-compilation optional but recommended for ensuring smooth deployment. - -To compile you can use the `libra move` tool with the command `libra move compile --package-dir ../../tools/txs/tests/fixtures/test_publish` - -#### Named Addresses -When deploying a module, the address in the module must match the address of the account (signer) performing the publication. There are two approaches to handle addresses in your Move package: - -1. **Hard-coding the Address**: - You can specify the address directly in the `Move.toml` file. For example: - ```toml - [package] - name = 'test_publish' - version = '1.0.0' - - [addresses] - this_address='0000000000000000000000000000000069a385e1744e33fbb24a42ecbd1603e3' - ``` - - And in your Move contract: - ```move - module this_address::message { - // Your code here - } - ``` - -2. **Setting the Name at Publishing**: - If you prefer not to hard-code the address, you can use the `--named-addresses` CLI argument to dynamically set the address at the time of publishing. The argument takes pairs of strings: an alias (key) and an address (value). - ```sh - txs publish --package-dir ./path/to/Move/code --named-addresses "this_address=0x1234" - ``` - -### Publish a Smart Contract -- **Function**: Deploys smart contracts (Move modules and scripts) onto the Libra blockchain. -- **Syntax**: `libra txs publish --dev|--package-dir |--output-dir | --skip-fetch-latest-git-deps|--bytecode-version ` -- **Parameters**:. - - `--dev` (optional): Enables dev mode, which uses all dev-addresses and dev-dependencies. Dev mode allows for changing dependencies and addresses to the preset [dev-addresses] and [dev-dependencies] fields. This works both inside and out of tests for using preset values. Currently, it also additionally pulls in all test compilation artifacts - - `--package-dir `: Path to a move package (the folder with a Move.toml file) - - `--output-dir ` (optional): Path to save the compiled move package. Defaults to `/build` - - `--skip-fetch-latest-git-deps` (optional): Skip pulling the latest git dependencies.If you don't have a network connection, the compiler may fail due to no ability to pull git dependencies. This will allow overriding this for local development. - - `--bytecode-version ` (optional): Specify the version of the bytecode the compiler is going to emit -- **Examples**: - - Publishing a Module: - ``` - libra txs publish --module /path/to/module - ``` - This command publishes a module located at `/path/to/module`. - - ---- diff --git a/docs_old/cli-tools/txs/transfer.todo b/docs_old/cli-tools/txs/transfer.todo deleted file mode 100644 index 40876e9b..00000000 --- a/docs_old/cli-tools/txs/transfer.todo +++ /dev/null @@ -1,26 +0,0 @@ ---- -sidebar_position: 3 -description: 'Transfer Coins' ---- - -# Txs - Transfer - - - -## Description -This is a simple tool to transfer coins from one account to another. It is also used to create an account on chain. If an account is created with the `libra wallet` tool, it does not exist on chain until it has a non zero balance - - -### Transfer -- **Function**: Transfers digital assets (e.g., tokens, coins) from one account to another on the 0L Network. -- **Syntax**: `libra txs transfer --to-account --amount ` -- **Parameters**: - - `--to-account `: The address of the recipient's account. - - `--amount `: The amount of digital asset to transfer. -- **Example**: - ``` - libra txs transfer --to-account 0x1234 --amount 1000 - ``` - This command transfers 1000 units of the digital asset to the account with address `0x1234`. - ---- diff --git a/docs_old/cli-tools/txs/upgrade.todo b/docs_old/cli-tools/txs/upgrade.todo deleted file mode 100644 index 7cffdc5b..00000000 --- a/docs_old/cli-tools/txs/upgrade.todo +++ /dev/null @@ -1,45 +0,0 @@ ---- -sidebar_position: 3 -description: 'Upgrade VM Libraries' ---- - -# Txs - Upgrade - - - -## Description -The `libra txs upgrade` subcommand includes a set of subcommands tailored for validator operations. These commands facilitate actions like proposing and voting on network upgrades,. - -### Upgrading the Network -This tool is specifically for Hot upgrades. Hot upgrades to 0L Move framework (AKA "stdlib") require no halting of the network and are achieved with the Upgrade Oracle. This can be done when there are non-breaking changes to the vm (in Rust), and the stdlib (Move) has migrations in place in case of schema changes. - -A detailed explanation can be found [here](/validators/hot-upgrades) - -## Upgrade Transactions - -### Propose an Upgrade -- **Syntax**: `libra txs upgrade propose --proposal-script-dir --metadata-url ` -- **Function**: Initiates a proposal for a network upgrade. -- **Parameters**: - - `proposal-script-dir`: Directory containing the compiled proposal script. - - `metadata-url`: URL describing the proposal. -- **Example**: - ``` - libra txs upgrade propose --proposal-script-dir /path/to/script --metadata-url "http://example.com/proposal" - ``` - -### Vote on an Upgrade -With txs anyone with governance authority (the epoch's validators as of V7), can submit a vote in favor (or against it with --should-fail) -- **Syntax**: `libra txs upgrade vote --proposal-id [--should-fail]` -- **Function**: Casts a vote on an existing upgrade proposal. -- **Parameters**: - - `proposal-id`: On-chain ID of the proposal. -- **Example**: -- **Vote YES on an Upgrade** - ``` - libra txs upgrade vote --proposal-id 12345 - ``` -- **Vote NO on an Upgrade** - ``` - libra txs upgrade vote --proposal-id 12345 --should-fail - ``` diff --git a/docs_old/cli-tools/txs/validator.todo b/docs_old/cli-tools/txs/validator.todo deleted file mode 100644 index 731aa774..00000000 --- a/docs_old/cli-tools/txs/validator.todo +++ /dev/null @@ -1,106 +0,0 @@ ---- -sidebar_position: 3 -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. - - -## 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 --expiry ` -- **Parameters**: - - `bid-pct`: Percentage of the nominal reward bid for validator set entry. - - `expiry`: Set the expiry epoch that your bid expires on. -- **Example**: - ``` - libra txs validator pof --bid-pct 123.4 --expiry 1000 - ``` - -### Register Validator -> Make sure you have your config at `~/.libra/libra.yaml` with `libra config init` - -- **Function**: Registers a new validator on the network. -- **Syntax**: `libra txs validator register [--operator-file ]` -- **Parameters**: - - `operator-file`: the file with a validators operator information. Usually found in ~/.libra/operator.yaml. -- **Example**: - ``` - libra txs validator register --operator-file ~/.libra/operator.yaml - ``` - -### 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: - -``` ---- -operator_account_address: 00000000000000000000000000000000d1281de242839fc939745996882c5fc2 -operator_account_public_key: "0x264cb0b3463a61177bc2a33a1b81df55cf92177ab216a0460f6aba57b5b0d2f2" -consensus_public_key: "0xb99f4b268d6aac24e4ca47f08faa2cb8aead75d2f495982c736dce340edd8a5bcba2d052e23f135e0ccc13136be16e97" -consensus_proof_of_possession: "0xb382b44e9a115e044da4f9bcc1bd8f75d819a029644ff2221b019bc20dea08f7ebfc1ea47d3e1d4a0c44c4207865e972116ef75af121bb9baefed3fb8e71e98b540da60bbd0375e70dd8df24f9e85ed69bacac65a6b440dd476b27fdfdf5475fe" -validator_network_public_key: "0x0a3cab5f2ecb29bdb4a9efe1dd4576feacefe4ec74ab7ef65d472bbb4461804d" -validator_host: - host: 35.86.200.84 - port: 6180 -full_node_network_public_key: ~ -full_node_host: ~ - -``` - -- **Function**: Updates network addresses for a validator and associated full nodes. -- **Syntax**: `libra txs validator update --operator-file ` -- **Parameters**: - - `operator-file`: the file with a validators operator information. Usually found in ~/.libra/operator.yaml. -- **Example**: - ``` - libra txs validator update --operator-file ~/.libra/operator.yaml - ``` - -### 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 [--revoke]` -- **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 - ``` -- **Remove a vouch for a validator** - ``` - 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. - -- **Function**: Manages Jail functions within the network. -- **Syntax**: `libra txs validator jail --unjail-acct ` -- **Parameters**: - - `unjail-acct`: The account of the validator a voucher would like to unjail -- **Example**: - ``` - libra txs validator jail --unjail-acct 0xC7394B8AF7BC3BDB9258C53DFFDA7F2B - ``` - ---- diff --git a/docs_old/cli-tools/wallet.todo b/docs_old/cli-tools/wallet.todo deleted file mode 100644 index c3bf1513..00000000 --- a/docs_old/cli-tools/wallet.todo +++ /dev/null @@ -1,62 +0,0 @@ ---- -sidebar_position: 3 -description: 'Create an Account' ---- - -# Wallet - -## Description -The Libra wallet tool provides essential functionalities for managing digital wallets within the 0L Network ecosystem. It is designed to handle digital currencies and assets through secure key management, account maintenance, and transaction processes. - -### Core vs. Legacy Wallets -The wallet tool comprises two main components: `core` and `legacy`. In previous Libra versions(V5 and below) the software used the legacy format, while Legacy wallets were migrated with the hard fork from V5 -> V6.9.0 it is recommended users now create wallets using HKDF. Here is an outline that represents different approaches and functionalities of each of the wallet types: - -#### Legacy Wallet -- **Compatibility**: Maintains functionality and compatibility with older wallet versions. This includes handling legacy address formats and key derivation schemes. -- **Simpler Security Model**: Features a less complex security model, evident from the unencrypted storage of mnemonics and simpler key management. -- **Transition Support**: Acts as a transitional component for users migrating from older systems to the newer, more secure core wallet system. - -#### Core Wallet -- **Modern Cryptography**: Utilizes ed25519 and Hierarchical Key Derivation Function (HKDF) based on RFC 5869, aligning with current cryptographic standards. -- **Key Management**: Manages a variety of key types, including mnemonic phrases, with a focus on security and compliance with modern standards. -- **Future-Proof**: The core wallet is an evolving component, indicating ongoing improvements and updates to maintain security and feature enhancements. - -## How to Use the CLI Tool -The wallet CLI tool offers a user-friendly command-line interface for interacting with the 0L Network. Key functionalities include: - - -### Key Generation -- **Syntax**: `libra wallet keygen [--mnemonic ] [--output_dir ]` -- **Function**: Generates new keys and account addresses. Can recover accounts from mnemonics. -- **Example**: - - To generate a new key and account address: - ``` - libra wallet keygen --output_dir /path/to/directory - ``` - - To recover an account using a mnemonic: - ``` - libra wallet keygen --mnemonic "your mnemonic phrase here" - ``` - -### Legacy Operations -- **Syntax**: `libra wallet legacy [--display] [--output_path ] [--keygen]` -- **Function**: Manages operations related to legacy wallets, including displaying private keys, saving keys to a specified path, and generating new keys in the legacy format. -- **Example**: - - To display private keys in the legacy format: - ``` - libra wallet legacy --display - ``` - - To save legacy keys to a file: - ``` - libra wallet legacy --output_path /path/to/keys - ``` - - To generate new keys in the legacy format: - ``` - libra wallet legacy --keygen - ``` - ---- - - - ---- diff --git a/docs_old/community programs/_category_.json b/docs_old/community programs/_category_.json deleted file mode 100644 index 4107173d..00000000 --- a/docs_old/community programs/_category_.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "label": "Programs", - "position": 3, - "link": { - "type": "generated-index", - "description": "Third-party programs by community members" - } -} diff --git a/docs_old/community programs/a_good_list.md b/docs_old/community programs/a_good_list.md deleted file mode 100644 index edfcea2d..00000000 --- a/docs_old/community programs/a_good_list.md +++ /dev/null @@ -1,316 +0,0 @@ -

A Good List

source: [https://github.com/0LNetworkCommunity/a-good-list/edit/main/README.md](https://github.com/0LNetworkCommunity/a-good-list/edit/main/README.md) - -

What

- -A Good List is a collection of addresses on 0L Network which will collect donations for named orgs. It also includes a "router" address which splits donations according to weight. The weight is updated on a monthly basis. - -The addresses here are 0L addresses. This program may extend someday to other blockchains or assets. - -

Why

- -Blockchain engineers, operators, and other participants can make life-changing sums of money from early participation in new networks. Many individuals seek to automatically donate some of their rewards to organizations. Donating is hard to reason about, and ultimately leads to inaction. - -This list makes it easy for an 0L miner to set "autopay" instructions to donate. - -

What donations are for

- -They go to entities on the list, to do what they see fit to do with them. The router is just a pass-through to the wallets of entities. Currently (April 2021) the automation of this process is a work in progress, see more below. - -

How does the router split the donations?

- -The router is initialized with an equal weight for all wallets. Every donation that comes in the first month is split evenly. The split for the subsequent months can be updated by the donors of the previous month. - -The donors to the routing address can optionally submit on a monthly basis a ranked-choice-vote on the charities they prefer. The weights will be updated accordingly. - -Donors can add orgs to the list. If a new org appears in 2/3rds of the ranked-choice votes, the name is added to the list. - -Orgs can be removed from the list. As above, if 2/3rd of voters excludes an org from their votes, the name is removed from future finds received by the router. The wallets will appear elsewhere for historical reference. - -

Claiming the values in a wallet

- -Recipients: If you are an org named below, just reach out. We'll establish that you are, who you say you are, and you can take custody of the accounts. - -Note to donors: There may be a scenario where a charity is incapable of claiming the wallet. If so, a reasonable policy would be to assume it is unclaimed property, and it can be distributed pro-rata to the other wallets which have been claimed. Let's say April 2022 is the window for claiming it. - -

Work in Progress (as of July 2021)

- -For expediency this project was started without any automation (no smart contract) at and this list and distribution is manually administered by Water & Stone LLC (a company involved in blockchain software development, including for 0L network). We do not intend to operate this program indefinitely. Until the smart contracts are developed formally donations are currently given to Water & Stone, and we submit 0L "autopay" transactions on a monthly basis to the wallets on the list. Water & Stone is taking no fee on these. - -Currently Water & Stone has sole access to the custody platform for these wallets. We are seeking to transfer that to a third party (not Water & Stone) for long-term administration. Please reach out directly if you have a sustainable solution for custody and automation. - -Water & Stone will mark this address as a โ€œCommunityWalletโ€ on chain. By that we mean: - -- that we will only disburse funds after polling the community. -- funds will only be transferred to an 0L SlowWallet, which releases funds over time. -- we allow 2/3 of validators (by voting power) to vote to reject our transactions. -- if an epoch's validator set decides to sunset this account (burn values and make inaccessible) for any reason, we will oblige. - -

Disclaimer:

- -The charities below may not even be aware of the list, or of the wallet assigned to them. To be clear, do not assume any org on the list is endorsing: a) the list itself b) the 0L chain c) donors d) et cetera, et cetera. - ---- - -

The Router

- -Address: BCA50D10041FA111D1B44181A264A599 - -

The List (alphabetical):

- - - - - - - - -{' '} - - - - - - -{' '} - - - - - - -{' '} - - - - - - -{' '} - - - - - - -{' '} - - - - - - -{' '} - - - - - - -{' '} - - - - - - -{' '} - - - - - - -{' '} - - - - - - -{' '} - - - - - - -{' '} - - - - - - -{' '} - - - - - - -{' '} - - - - - - -{' '} - - - - - - -{' '} - - - - - - -{' '} - - - - - - - - - - - - - - -{' '} - - - - - - -{' '} - - - - - - -{' '} - - - - - - -{' '} - - - - - - -{' '} - - - - - - -{' '} - - - - - - -{' '} - - - - - - -{' '} - - - - - - -{' '} - - - - - - -{' '} - - - - - - - - - - - -
NameAddressWeight
Action against hunger06697386CDDABB634CEB0572D4423E34 -

1

-
Acumen4858B43E3A68893B51AF12C6D6BB5FB0 -

1

-
Amnesty International66BE7F0A8B34ADC4E00CCC11F531B2C0 -

1

-
BRACC50E5252CDDD65785F038FF15FEC5D0A -

1

-
Care InternationalD17AAA79DDD10CC3D96A16A135851638 -

1

-
Danish Church Aid4D09392F4FBE6094FE8D281C58887B16 -

1

-
Danish Refugee Council3D5EF9D9848D82C1FFD1F0C7183B1DA9 -

1

-
Girls Who Code7407E489953A0F64E5D70A80CB1B5CAE -

1

-
Give Directly20DDE7374220DCBB89145704833A6FF3 -

1

-
Give Well4CB31C687FD20DA3C2591B6DFC1F19F5 -

1

-
Habitat for Humanity98DA3CB6553C8DE6DFC840F4FD3EE5AF -

1

-
Innovation Norway HumanitarianF9AE13D90338B5CA9B391B1626F0503D -

1

-
International Committee of the Red Cross (ICRC)424428DB94430AA85EA9723E6C503B95 -

1

-
International Rescue CommitteeCD68A370A556F784256F9D35597328E8 -

1

-
The Life You Can Save - 90/10 Fund22DFEA36CE3456D80483BFF28E86910C -

1

-
Mรฉdecins Sans FrontiรจresD3926848A6AFC26ACB3E08C5818BCEAF -

1

-
Mercy Corps68C88FA01E8F61353FF350991B3CEAB6 -

1

-
Open Society Foundations783590B8559522C7B105664FE5563AD0 -

1

-
Oxfam63499CAA93631567891DB9AF279F2C5F -

1

-
Plan International572C43CD421F0E6DDFCFB0934EC4D5D1 -

1

-
Save the ChildrenA711D4E5E0B4FC661111FDC13488E740 -

1

-
Team HumanityB989372FF8986BC7373C51688ED7C735 -

1

-
Trust Alliance19CB71BD9864FB0CBC782CA293637D92 -

1

-
Unicef672178939A5C97E7AFC23BFE3D8407BC -

1

-
Water.Org58AFC42F3CEF6CB79D669A0F0E75DC34 -

1

-
Women's World Banking8AFA0A41F7FCF9147C57991729B8FF20 -

1

-
World Food Program4B1F1544A42FDD2F15F82A19704F3FC2 -

1

-
World Wildlife FundA72834D73B4A456CFFE4F5CE059F03E2

1

diff --git a/docs_old/community programs/application_studio.md b/docs_old/community programs/application_studio.md deleted file mode 100644 index 9df4e318..00000000 --- a/docs_old/community programs/application_studio.md +++ /dev/null @@ -1,8 +0,0 @@ -Newlab (newlab.com) as a platform strives to pair frontier technology with real-world challenges and partners. Our multidisciplinary community and mothership at the Brooklyn Navy Yard is made up of over 750 members and 160 companies. We are a high-performing community of inventors, engineers, scientists and entrepreneurs reimagining 21st century infrastructure. Newlab has extensive experience pairing frontier technology with legacy industries and cities, investing in early-stage ventures, identifying winning teams as well as directly contributing to the growth of new I.P. and companies from the ground up. - -In addition to being a member of the 0L community and early miner, Newlab is starting a program to back teams that have clearly defined plans to leverage 0L for applications with real-world, measurable impact and utility (the โ€œ0L Application Studioโ€). Newlab is excited to serve as a platform to foster these real-world applications of 0L and help these efforts partner with industry to transform or leapfrog existing legacy infrastructure. - -If you would like to support this program, your contributions are welcome at: **bc25f79fef8a981be4636ac1a2d6f587**. - -Donations will be used to fund awards of the program, as determined by Newlabโ€™s team in partnership with the 0L community. Newlab intends to be proactively involved in helping studio partners realize applications that have utility, impact and scale. In order to cover administrative costs, Newlab will collect 10% of the funds received. - diff --git a/docs_old/community programs/danish_red_cross_humanitarian_fund.md b/docs_old/community programs/danish_red_cross_humanitarian_fund.md deleted file mode 100644 index cd819d44..00000000 --- a/docs_old/community programs/danish_red_cross_humanitarian_fund.md +++ /dev/null @@ -1,41 +0,0 @@ - -## Introduction - - - - -The Danish Red Cross (DRC) has existed under the Red Cross Mandate since 1876\. In Denmark, 34,000 volunteers are engaged in supporting the Red Cross vision. Currently, DRC has long-term partnerships in 30 countries and deploys US$200M on international activities, annually. It acts before, during and after disasters and health emergencies to meet the needs and improve the lives of vulnerable people. It does so with impartiality as to nationality, race, gender, religious beliefs, class, and political opinions. Under the auspices of Red Cross humanitarian principles, the DRC will administer the Humanitarian Digital Transformation and Systems Change Fund (the Fund) which aims to improve outcomes for communities affected by humanitarian crises by identifying, testing, and cultivating more effective and scalable technology and data enabled solutions. - - - - -## Management Fee - - - - -There will be a one time 7% management fee on all funding donated to the Fund. This fee is in-line with standard Danish Red Cross fees across all funding streams. Proceeds from the management fee will be used to cover operating expenses, such as program assessment, communications, legal, auditing, staff, office supplies, and other administrative costs. - - - - -0L Wallet Address **B31BD7796BC113013A2BF6C3953305FD** - - - - -## Examples of DRCโ€™s technology driven humanitarian programs - - - - -The Danish Red Cross has already engaged in a number of blockchain related programs that seek to stimulate system change to traditional humanitarian assistance modalities. The following two examples: - - - - - - -| **Community Inclusion Currencies** | **Click here for video: https://youtu.be/bHM1DRHSUPw** | **Click link for information site: http://cichub.org** | -| --- | --- | --- | -| **Volcano Catastrophe Bond** | **Click here for video: https://youtu.be/hWUjRM4BS78** | **Click link for information site: https://catbond.org** | diff --git a/docs_old/community programs/deep_technology_innovation_program.md b/docs_old/community programs/deep_technology_innovation_program.md deleted file mode 100644 index b16461de..00000000 --- a/docs_old/community programs/deep_technology_innovation_program.md +++ /dev/null @@ -1,32 +0,0 @@ - -BlockScience Inc is an engineering research and development firm, which has been operating in and around the distributing computing field since 2017\. BlockScience has collaborated with a wide range of industry and academic researchers on a variety of topics, including but not limited to mechanism design, distributed computing, collective intelligence and the social implications of algorithmic policymaking. - - - - -BlockScience has established the Deep Technology Innovation Program in order to create a pathway for the 0L network to provide funding to the academic fields that technology and other cryptonetworks rely upon, not only for technological advance but also to support the interdisciplinary research which creates the cultural context for ethical application of this technology. - - - - -Recent events have shown us that we cannot rely on our web2 corporate empires to pursue technology research ethically. Furthermore, our academic institutions are far too reliant on funding with implicit strings attached. Academic freedom includes freedom from financial coercion, which necessitates sources of funding whose mandate is the pursuit of knowledge in service of the public good in accordance with sound epistemilogical practice. - - - - -This Deep Technology Innovation Program will provide opportunities for best in class academic and industry research teams to pursue courses of research aimed at innovation of the internet (from cables all the way to human users) as an information infrastructure. This infrastructure is the nervous system of our global society, the most critical and far reaching public good surpassed in its importance only by the earth itself. - - - - -The program will solicit research proposals, evaluate proposals based on their scientific merits, team qualifications and the potential impact of the research. Solicitation and evaluations will be performed by knowledgeable researchers including both BlockScience staff and third-party experts. - - - - -Donations to the Deep Technology Innovation Program are accepted at the address:ย **BB6926434D1497A559E4F0487F79434F**. - - - - -Donations will be used to award grants for potential high impact projects. This address is a special class of โ€œCommunityWalletโ€ on chain. Funds will only be disbursed after polling the community. Specifically, funds will be transferred to another address only if 2/3 of validators in an epoch approve (by voting power). To cover costs of managing this program, BlockScience may receive an administrative fee up to 4% of the funds awarded to teams; this dispersement is also subject to community approval. As a CommunityWallet if the validators see fit to Sunset this account, its operators will accommodate. diff --git a/docs_old/community programs/ftw_ongoing_full_time_workers_program.md b/docs_old/community programs/ftw_ongoing_full_time_workers_program.md deleted file mode 100644 index 7b122dcc..00000000 --- a/docs_old/community programs/ftw_ongoing_full_time_workers_program.md +++ /dev/null @@ -1,130 +0,0 @@ - -The iqlusion FTW Program aims to collect ongoing donations, and redistribute those donations to any engineers working full-time on the 0L platform on a monthly basis (collectively the FTW). - - - - -**Address: 3A6C51A0B786D644590E8A21591FA8E2** - - - - -## Problem Statement - - - - -There are two types of contributions needed for the success of open-source projects: - - - - -1. Isolated tasks which can be delivered independently without extensive coordination nor holistic view of the platform. Those contributions are a good fit for bounties, and this is customary in open-source projects. -2. Another type of contribution requires intimate knowledge of a wide range of system components, and can only reasonably be achieved with a high commitment of hours over the long term. Bounties are generally not a good fit for these contributors since they do not provide continuity, sustainability and predictability. - - - - -\#1 is a largely solved problem. For \#2 above, there are perverse incentives in the early days of a network. - - - - -In the early days, a prospective engineering contributor has a choice between A) running a miner plus contributing engineering and B) running a miner and not contributing. At the early stages of a network โ€œBโ€ is the rational choice. - - - - -Incorporating a social consensus of donating to such a program, plus redistributing to engineering could make โ€œAโ€ the rational choice. - - - - -Why not just use funds from an engineering bounty program also for full-time engineers? From the community perspective, funding ongoing contributions from bounties is expensive in early days. Bounties must compete with earnings from node operations (mining). As such, given that at the beginning of a network there is a combined need for an intense amount of work while the value of mining is high, any funds set aside for long term engineering efforts (e.g. over the course of a decade) could quickly become depleted. Additionally having a separate program allows donors more fine grained options for donating. - - - - -## Design of this Program - - - - -This is an experiment. - - - - -All donations that come into the Program during a given month, go out in the same month to the FTW - an open group of full-time engineers, committing code to the 0L source repositories. - - - - -### To be considered a full-time engineer - - - - -* Commit a minimum of 20 hours per week, **AND**, -* Have weekly high quality and high impact deliverables in: software, architecture, systems, project management. **AND**, -* You attend the engineering meetings. - - - - -### How rewards are split - - - - -TLDR; The engineering group decides. - - - - -Currently (Sept 2021\) the members of the group will vote to affirm if each individualโ€™s contributions were above the hourly threshold AND constitute a milestone towards platform evolution and sustainability. Those whose contributions do not meet these criteria, will be gently and gracefully reminded of the objectives of the Program. The group can decide on how to split rewards on a monthly basis. - - - - -### How do you enforce? - - - - -There is no magic here. - - - - -The full-time engineers are a small group, and we can make honesty assumptions, and fraud should be easy to catch. Any individuals claiming payments from this address will have work that is publicly visible on github. Reports could be made based on that activity. Since the members of the fulltime group ultimately decide on the split, they have an incentive to enforce that their share of the donations does not get diluted. - - - - -Program viability presumes there is strong social consensus that FTW workers are needed by the community, and the donors will self-police prisonerโ€™s dilemma scenarios. Donors will donate when they see value being produced by the group, and advocate for more donations. Donations will stop when the value is not evident. - - - - -### Formalities - - - - -Provisionally, the FTEP program is administered by iqlusion inc. Funds sent to this wallet are pass-through; destined to iqlusion for onward distribution in the same month. Futurely, a different entity may administer this program. Iqlusion has no claim nor fee on the funds sent to this address. The community will be notified in customary channels if ownership of the address changes. - - - - -For transparency the destination address is managed by a smart contract called a โ€œcommunity walletโ€. This allows any members of consensus validator set to review transactions sent from it, and delay and ultimately freeze transactions from the account. - - - - -## What is Iqlusion? - - - - -Iqlusion is a blockchain infrastructure company that has been building and operating infrastructure. We were one of the first Proof of Stake validator companies. We are currently primarily focused on protocol development. diff --git a/docs_old/community programs/human_rewards_program.md b/docs_old/community programs/human_rewards_program.md deleted file mode 100644 index fd6ead26..00000000 --- a/docs_old/community programs/human_rewards_program.md +++ /dev/null @@ -1,39 +0,0 @@ - -## What - - - - -This is a donation to a program to allow anyone that can verify they are human to receive some coins for some human work. This will likely be implemented as a Proof of Human with Captcha through a provider, or by leveraging proof of service (on Github or Twitter). - - - - -## Who - - - - -Additionally 10% of these funds will be earmarked for exceptional contributors to blockchain technology and social innovation. Not for the big names, but people who gave more than they received from crypto. Donors will be able to suggest github or twitter account handles. - - - - -## How - - - - -This account is operated via smart contract. And all outbound transactions will be initiated by an Oracle, yet to be implemented. Additionally this address has a community wallet tag, which means that we allow validators to review the txs, and block anything which appears to be incompatible with the goals above. - - - - -## Where - - - - -Donations can be sent here:ย **F605FE7F787551EEA808EE9ACDB98897** - - diff --git a/docs_old/community programs/moonshot_program.md b/docs_old/community programs/moonshot_program.md deleted file mode 100644 index 6f50c916..00000000 --- a/docs_old/community programs/moonshot_program.md +++ /dev/null @@ -1,35 +0,0 @@ - -Liberators of Libra LLC is a small software development company involved in blockchain software development, including for 0L network. The company has not raised venture capital nor has any investment partners. - - - - -Inspired by the well-known Xprize awards, we think large and meaningful rewards are necessary to materialize frontier technologies which are ambitious, speculative, and non-obvious. As such, LOL has established โ€œMoonshot Projectsโ€. This program sponsors large rewards for teams with extraordinary background in technology, and a plausible path to deplying said technology in society. We are seeking breakthrough use-cases which depend on yet-unrealized innovations in distributed systems and cryptography. Success for โ€œMoonshotsโ€ means producing a jump discontinuity for any industry or any human activity, but not necessarily immediately. - - - - -The program principally aims to a) identify opportunities, b) match teams to opportunities, and c) manage an expert-led evaluation process for technical achievements. Financial awards or grants for technical achievements will be contributed from LOL proprietary funds. - - - - -Donations to LOL for the Moonshot Program are accepted at the 0L account: **2057BCFB0189B7FD0ABA7244BA271661**. - - - - -Donations will be used to fund awards of the program. For professional administration of the resources of the program LOL will retain an administrative fee up to 5% of the funds awarded to teams. - - - - -LOL will mark this address as a โ€œCommunityWalletโ€ on chain. By that we mean: - - - - -* that we will only disburse funds after polling the community. -* funds will only be transferred to an 0L SlowWallet, which releases funds over time. -* we allow 2/3 of validators (by voting power) to vote to reject our transactions. -* if an epochโ€™s validator set decides to sunset this account (burn values and make inaccessible) for any reason, we will oblige. diff --git a/docs_old/community programs/rxc_research_and_experimentation_0l_fund.md b/docs_old/community programs/rxc_research_and_experimentation_0l_fund.md deleted file mode 100644 index 3917254d..00000000 --- a/docs_old/community programs/rxc_research_and_experimentation_0l_fund.md +++ /dev/null @@ -1,22 +0,0 @@ - -RadicalxChange Foundation, a 501ยฉ3 nonprofit, seeks to build a coherent and sustainable new political economy. - - - - -We are establishing a Research and Experimentation fund advancing new incentive structures. By encouraging investment in public goods, optimizing the use of club goods, and reexamining old assumptions about property and democracy โ€“ as well as by building bridges between academic rigor and public imagination โ€“ we seek to lay foundations for new institutions that allow everyone to participate in the value they co-create. - - - - -We believe that blockchain systems such as 0L have a vital role to play in instantiating fairer and more decentralized economic systems. Our work with the 0L community will complement our work with governments, academics, and private teams committed to building better systems for group decisions, public engagement, and economic participation. Examples of such work include our implementations of quadratic voting with governments in Colorado and Brazil, and our work with socially-minded real estate developers on partial common ownership licenses. - - - - -0L donations to RadicalxChangeโ€™s Research and Experimentation fund are accepted at this address: **C19C06A592911ED31C4100E9FB63AD7B**. - - - - -No more than 15% of donations will go to administration and overhead, and at least 85% will support experiments, studies, and implementations of novel institutional designs. diff --git a/docs_old/community programs/social_infrastructure_program.md b/docs_old/community programs/social_infrastructure_program.md deleted file mode 100644 index d39e6d2a..00000000 --- a/docs_old/community programs/social_infrastructure_program.md +++ /dev/null @@ -1,115 +0,0 @@ - -Social infrastructures complement technical infrastructures provided by blockchain networks. This program is designed to provide capital to fund a wide range of benefits to 0L members in alignment with the mission, vision and values of the community. - - - - -## What is Social Infrastructure? - - - - -Social infrastructure is also calledย *โ€œsoft infrastructureโ€* - - - - - -> Soft infrastructure refers to all the institutions that maintain the economic, health, social, environmental, and cultural standards of a country. -> -> \~Wikipedia Entry onย [Infrastructure](https://en.wikipedia.org/wiki/Infrastructure) - - - - -Unlike a country, peer-to-peer networks are fundamentally opt-in. They form a new kind of constituency distinct from nation-states. Peer-to-peer networks bear a closer resemblance to other opt in systems providing membership benefits such asย [credit unions](https://en.wikipedia.org/wiki/Credit_union)ย andย [professional associations](https://en.wikipedia.org/wiki/Professional_association). Like benefits offered by professional associations and credit unions; members may help define and opt into benefits programs. - - - - -## Why Fund Social Infrastructure? - - - - -It is increasingly common for community and industry organizations to offer benefits programs to address welfare gaps emerging in society. An example one such program isย [Freelancers Union](https://www.freelancersunion.org/)ย which specifically addresses the benefits gaps for freelancers relative to their peers. The growing web3 ecosystem suffers from many of the same benefits gaps that freelances suffer from, and some case more sever gaps may emerge depending on the members geography and/or specific industry. - - - - -While the decentralized nature of peer-to-peer networks decouple them from any particular industry or geographic region, they do not eliminate their membersโ€™ physical needs. Any membership benefits programs that aims to address social and economic welfare will need capital. - - - - -By including a social infrastructure program in the 0L community wallet set, validators make it possible for OL to actualize our vision of providing social infrastructure for its members. Availability of capital significantly reduces the financial burden of deploying and operationalizing such programs. - - - - -## How Will These Resources be Used? - - - - -The resources collected by the Social Infrastructure Program will supply capital to membership benefits programs focus on social and economicย *welfare*. The term welfare is often used for specific government programs because benefits programs or provided or mandated by. However, here we reimagine benefits programs targeting social and economic welfare as social infrastructures providedย *for and by*ย communities to serve the needs of those communitiesโ€™ members, as whole persons, not merely as economic actors. Welfare ecompasses support intend to ensure that members of the community meet basic human needs. A nonexclusive list of examples: - - - - -* Housing -* Health -* Education -* Physical Safety -* Economic Security -* Arbitration \& Dispute Resolution - - - - -Building on the example of the Freelancers Union, an example of the type of initiative this program might fund is a health plan managed by the association which members may opt into. - - - - -However, the long term vision for such programs extend beyond typical employee benefits programs to encompass support for any social infrastructure the community collectively deems necessary to redress welfare deficiencies identified amongst the membership. - - - - -## Practical Considerations - - - - -Since this programโ€™s primary purpose is to provide capital to social infrastructure initiatives in the future, it is not expecting to deploy any capital for at least a year after the launch of the 0L mainnet. It may be much longer as social infrastructure has significant dependencies. - - - - -*There are other 0L programs focused on research, design, development and deployment of social infrastructures and the technical infrastructures which enable them.* - - - - -## Donation Details - - - - -Donations to the Social Infrastructure Program are accepted at the address:ย **19E966BFA4B32CE9B7E23721B37B96D2**. - - - - -Donations will be used to cover the capital costs of specific social infrastructure initiatives. - - - - -We aim to disburse program funds in accordance with community wishes. The program address is deployed with automation: it is a class of โ€œCommunityWalletโ€ on chain. Specifically, funds will be transferred to another address unless 2/3 of validators reject, for any reason. - - - - -To cover costs of managing this program, BlockScience may receive an administrative fee up to 4% of the funds awarded to teams; this disbursement is also subject to community approval. As a CommunityWallet if the validators see fit to Sunset this account, BlockScience will accommodate. We may transfer operation of this program to another entity (or entities) and in such an event the community will be consulted and notified. diff --git a/docs_old/community programs/the_iqlusion_engineering_program.md b/docs_old/community programs/the_iqlusion_engineering_program.md deleted file mode 100644 index 15f3f88b..00000000 --- a/docs_old/community programs/the_iqlusion_engineering_program.md +++ /dev/null @@ -1,27 +0,0 @@ - -Iqlusion intends to supervise the evolution and extension of 0L blockchain from itโ€™s current nascent form into a full feature base layer in the multichain world. We intend to establish a mature engineering program around 0L with design documents, ADR, pull requests and code review to ensure a stable and robust blockchain platform. Of particular interest to us is developing an engineering program to connect 0L to the Internet of Blockchains via support for Ethereum and IBC interoperability. - - - - -## The Onchain program - - - - -Funds donated to the iqlusion Engineering program will be used to establish and compensate community members engaged in engineering work both original work, maintenance and review of the code. - - - - -The Address of the iqlusion on-chain program wallet is **C906F67F626683B77145D1F20C1A753B**. - - - - -## What is Iqlusion? - - - - -Iqlusion is a blockchain infrastructure company that has been building and operating infrastructure. We were one of the first Proof of Stake validator companies. We are currently primarily focused on protocol development. diff --git a/docs_old/community programs/tip_jar.md b/docs_old/community programs/tip_jar.md deleted file mode 100644 index 76768056..00000000 --- a/docs_old/community programs/tip_jar.md +++ /dev/null @@ -1,16 +0,0 @@ -# TIP JAR -Source: https://github.com/infinite-game-llc/tip-jar/blob/main/README.md - -Core engineering on 0L has been an unfunded volunteer effort. For example, since about June 2019 the lead 0L developer -- github user `0o-de-lally` -- has contributed an estimated 5,060 man-hours exclusively to core protocol (last updated Sept 24th 2021). This effort was not compensated in any form. - -Please consider donating to Tip Jar at the 0L address: `2B0E8325DEA5BE93D856CFDE2D0CBA12`. When you donate by depositing to this address you will be effectively sharing your miner or validator with the program and as such with core contributors. - -This address is marked as a โ€œCommunityWalletโ€ on chain. As such funds from Tip Jar can only be transferred to an 0L "Slow Wallet" which releases funds over time. It implements the DonorVoice module so that donors to this wallet can veto transactions and ultimately freeze the account. The address is managed by Infinite Game LLC, a US validator company wholly owned by `0o-de-lally`. - - -# Other ways of contributing -If you are looking to fund short term needs, consider donating stable coins directly to `0o-de-lally`, see here: https://github.com/0o-de-lally/proof-of-work#short-term-help-pay-my-bills - -# April 2023 Update - -A test transaction with Tip Jar funds was to be disbursed to the A Good List, account on 0L on April 6th. diff --git a/docs_old/community programs/university_of_toronto_msrg.md b/docs_old/community programs/university_of_toronto_msrg.md deleted file mode 100644 index 81afe3f9..00000000 --- a/docs_old/community programs/university_of_toronto_msrg.md +++ /dev/null @@ -1,37 +0,0 @@ - -D is for Donations - - - - -## The Call for Research Donations - - - - -The Research Donations seek to attract funding to help support basic research and discovery targeted at distributed ledger and blockchain technology as well as distributed systems in the long term. - - - - -0L address: **1367B68C86CB27FA7215D9F75A26EB8F** - - - - -ETH address: **coming soon** - - - - -Safe for potential administrative costs, we intend for donations to be passed on as the same to the University of Torontoโ€™s Advancement Office in support of the research activities of the Middleware Systems Research Group -ย [msrg.org](http://msrg.org/). - - - - -Present and past members of the Middleware Systems Research Group have contributed to major open-source projects and created such projects in general and to 0L and Ethereum in particular. Insights gained from these activities, especially, the design, development, deployment and maintenance of non-trivial, globally operating systems are an invaluable asset in learning about as well as deriving research directions in distributed systems. These practical, real-world insights are difficult to derive from controlled laboratory experiments alone. - - - - -Donations will support research in the scope of MSRG. diff --git a/docs_old/community programs/working_group_key_roles.md b/docs_old/community programs/working_group_key_roles.md deleted file mode 100644 index caf5bc83..00000000 --- a/docs_old/community programs/working_group_key_roles.md +++ /dev/null @@ -1,17 +0,0 @@ -# Working Group Key Roles Program - -This program is intended to sponsor leaders (Key Roles) of the informal Working Groups for Open Libra (0L network) contributors. - -## Working Group Volunteers - -In January of 2022, the community adopted a proposal to implement an experimental informal community governance process called "Working Groups". Working groups are self-assembled, optional, and done on a volunteer basis. - -However, this experiment at times may need to use LIBRA for different purposes, including sponsoring some experts and leaders. This program exists to facilitate those cases. - -## Donation Address - -`87DC2E497AC6EDAB21511333A421E5A5` - -## Administration -This donation account is set to a Donor Voice setting, and is a multisig. The administrator of this program is Water & Stone LLC (a company involved in blockchain software development, including for 0L network). We -do not intend to operate this program indefinitely. diff --git a/docs_old/core-devs/_category_.json b/docs_old/core-devs/_category_.json deleted file mode 100644 index 55210805..00000000 --- a/docs_old/core-devs/_category_.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "label": "Core Devs", - "position": 4, - "link": { - "type": "generated-index", - "description": "For core platform engineering" - } -} diff --git a/docs_old/core-devs/dev_quick_start.todo b/docs_old/core-devs/dev_quick_start.todo deleted file mode 100644 index 61358e83..00000000 --- a/docs_old/core-devs/dev_quick_start.todo +++ /dev/null @@ -1,149 +0,0 @@ -# Libra Move Dev Quick Start - -## TL;DR - -### If you are running Move tests: - -- You must install `libra` cli tool to your PATH. - -``` -# in this repo -cargo build --release -p libra - - -# copy to a dir in your PATH -cp ./target/release/libra ~/.cargo/bin -# you may need to make it executable -chmod +x ~/.cargo/bin/libra - -# run framework tests with -cd ./framework/libra-framework -libra move framework test - -# run formal verification with -libra move framework prove -``` - -### If you are running e2e smoke tests: - -- You need our fork of `diem-node` before working on `libra-framework` -- compile `diem-node` to `$HOME/.cargo/bin` - -``` -git clone https://github.com/0LNetworkCommunity/diem -b release --single-branch -export RUST_DIEM_COIN_MODULE="libra_coin" -export RUST_DIEM_COIN_NAME="LibraCoin" -cd diem -cargo build --profile cli -p diem-node --target-dir ~/.cargo/bin - -# make it executable -chmod +x ~/.cargo/bin/diem-node -``` - -- export these env vars in your dev env, `~/.bashrc` or `~/.zshrc` - -``` -export RUST_MIN_STACK=104857600 -export DIEM_FORGE_NODE_BIN_PATH="$HOME/.cargo/bin/diem-node" -``` - -## Set up environment - -You should have two repos that you are working with. This one `libra-framework`, as well as `diem`. We'll need to build some executables from diem and install them on your dev machine. - -### Get the DIEM dependencies - -You need our fork of diem before working on `libra-framework` - -``` -git clone https://github.com/0LNetworkCommunity/diem -b release --single-branch -``` - -### check env - -This assumes that you have a `~/.cargo/bin` which is added to your environment's $PATH. - -### build executables - -You want to build the `diem-node` (for smoke tests only). - -There are two environment variables that are needed to use the correct Coin for -diem-node instead of a generic. - -`export RUST_DIEM_COIN_MODULE="libra_coin"` -`export RUST_DIEM_COIN_NAME="LibraCoin"` - -Note that the `--profile cli` compilation profile makes for much smaller binaries (e.g. `diem-node` goes from about 2GB to 30MB). - -``` -# env variables needed for compilation -export RUST_DIEM_COIN_MODULE="libra_coin" -export RUST_DIEM_COIN_NAME="LibraCoin" - -# build it -cargo build --profile cli -p diem-node --target-dir ~/.cargo/bin -# see you tomorrow (welcome to Rust). - -# next day, make it executable. -chmod +x ~/.cargo/bin/diem-node -``` - -Just check those executables appear in your path. -`which diem-node` - -Now you can run commands as below. - -## Running Move unit tests - -Change into a Move project dir (i.e., the directory with a Move.toml). - -`diem move test` - -optionally with filters: - -`diem move test -f` - -## Build a libra framework release for smoke tests (head.mrb) - -``` -cd ./framework -cargo run release - -``` - -Your release will be in `./releases/head.mrb`, you will need this for genesis and smoketests. - -Note for smoke tests: you must regenerate the .mrb file EVERYTIME YOU MAKE A CHANGE TO CORE MOVE CODE. Otherwise your tests will be against the old code - -## Running smoke tests - -Do it yourself: -Make sure you are in the root of the project. - -Note: there is an issue with the rust default stack size for tests which involve compiling, and then starting a local testnet - -``` -cd ./smoke-tests -export RUST_MIN_STACK=104857600 -export DIEM_FORGE_NODE_BIN_PATH="$HOME/.cargo/bin/diem-node" -cargo test -``` - -## Troubleshooting - -### 1. Building diem-node - -**Issue** - -If you encounter the following error: -`error[E0599]: no method named disable_lifo_slot found for mutable reference &mut tokio::runtime::Builder in the current scope` - -**Solution** - -You can resolve this issue by building with the following flag: - -``` -RUSTFLAGS="--cfg tokio_unstable" cargo build --profile cli -p diem-node --target-dir ~/.cargo/bin -``` - -This flag enables the unstable features required by the tokio runtime. diff --git a/docs_old/core-devs/formal_verification.todo b/docs_old/core-devs/formal_verification.todo deleted file mode 100644 index c3e0843b..00000000 --- a/docs_old/core-devs/formal_verification.todo +++ /dev/null @@ -1,98 +0,0 @@ -# Move Formal Verification - -The Move language includes a syntax for annotating code with `spec` -specifications which can be "formally verified". The syntax is purpose built for -Move. The stack behind the verification is based on `boogie`. - -You will need to install many dependencies for the Move test tooling as well as -boogie system libraries. - -## Quick Start - -1) get the libra cli with standard Move tools - -Compile the `libra` cli app, and have it in your executable PATH. -``` -cargo b --profile cli -p libra -cp target/cli/libra ~/.cargo/bin -chmod +x ~/.cargo/bin/libra - -# check it runs -libra -h -# this is the subcommand for the formal verification -libra move prove -h -``` - -2) Install the Boogie dependencies - -The `dev_setup.sh` can be run with these options: - -> -y install or update Move Prover tools: z3, cvc5, dotnet, boogie - -> -p update $HOME/.profile or ./bashrc - -``` -# run the installer -bash util/dev_setup.sh -yp - -# you may need to restart your shell, after env variables are set -# or .bashrc, or .zshrc - -bash ~/.profile - -``` - -Whatever terminal shell (or .zshrc) you are using you should check that these variable are exported: -``` -export DOTNET_ROOT="$HOME/.dotnet" -export Z3_EXE="$HOME/bin/z3" -export CVC5_EXE="$HOME/bin/cvc5" -export BOOGIE_EXE="$HOME/.dotnet/tools/boogie" -export SOLC_EXE="$HOME/bin/solc" -``` - -3) check it all works -you'll be running formal verification specs against `libra-framework` move -source. - -So test it on something we know to work -``` -cd framework/libra-framework - -# test the guid.move module -libra move prove -f guid -``` - -If you get a response without errors similar to the message below you are ready to -start. -``` -[INFO] 0.903s build, 2.585s trafo, 0.019s gen, 1.313s verify, total 4.820s -``` - -## Troubleshooting - -1) check then env vars were set up `echo $BOOGIE_EXE` -2) check that all the system libraries were installed `ls $HOME/.dotnet/tools/boogie` - -# Goals - -Formal verification priority for Libra should mainly check that the network does -not halt in operations conducted by the VM. - -1. epoch_boundary.move -Should never halt on reconfigure() -THough there are many downstream modules and functions from here, the largest -ones being: - - a. stake.move - - b. proof_of_fee.move - -2. coin.move - a. Transactions by VM should not halt - -3. slow_wallet.move - a. no transactions should bypass the slow wallet tracker. If there is a slow - wallet struct, a transaction should always alter it. - b. no account, not even the VM can withdraw above the unlocked limit. - c. the unlocked limit cannot be larger than the total. diff --git a/docs_old/core-devs/governance_fixtures.todo b/docs_old/core-devs/governance_fixtures.todo deleted file mode 100644 index 035d0402..00000000 --- a/docs_old/core-devs/governance_fixtures.todo +++ /dev/null @@ -1,36 +0,0 @@ -# Governance fixtures - -To test governance scripts and framework upgrade we place -tests in `tools/txs/tests` and fixture scripts in `tools/txs/tests/fixtures`. - -To generate these fixtures we use the `libra-framework cli`. - -## generate a noop governance script - -1. A template Move script package must exist. The CLI can create a template. - -``` -cd libra-framework -cargo r governance --script-dir ../tools/txs/tests/fixtures --framework-local-dir ./libra-framework --only-make-template -``` - -2. Don't make changes to this file. It should compile as-is. Run the cli tool again. -``` -cd libra-framework -cargo r governance --script-dir ../tools/txs/tests/fixtures/governance_script_template --framework-local-dir ./libra-framework -``` - -3. check the files are as expected -You should have -``` -../tools/txs/tests/fixtures/governance_script_template/ -| -+ - /sources/ -| | -| +-- governance_script_template.move -+ - Move.toml -+ - script_sha3 // hash of the script needed for authorization -+ - script.mv // compiled script which is submitted -``` - -You're done. \ No newline at end of file diff --git a/docs_old/core-devs/move_coding_conventions.todo b/docs_old/core-devs/move_coding_conventions.todo deleted file mode 100644 index cf4dfa69..00000000 --- a/docs_old/core-devs/move_coding_conventions.todo +++ /dev/null @@ -1,78 +0,0 @@ -# 0L Move Coding Conventions - -For core system code, we observe the following patterns. - -## Belt and Suspenders - -If you see "belt and suspenders" in the code, we are flagging the cases below. It means "yes this appears redundant, but we don't trust your fingers". - -Move is a new language, and devs won't have developed intuitions about it. Here we are safeguarding against developer errors, not malicious hacks. It's not only for logic bugs, typos, and incomplete work. Some Move language features make it that a fat finger, a git merge, a documentation commit, could expose a public API. - -For these cases you will see "belt and suspenders" implementations. They will seem inefficient and paranoid. But over time and over many developers, one of these may save from a catastrophic error. - -Wherever there are "critical mutations" i.e. state changes related to consensus, accounts values, or privilege escalation, we place multiple redundant checks on functions. - -1. Always authorize public functions: This should be obvious. Public functions which call critical mutations are authorized by `signer`s that are either the account holder or the `root` account. - -2. Friends: Assume a public function with critical mutation must be restricted by a `friend` permission, such that third party modules and scripts can only call through a limit number of paths. - -3. Write the private `fun` first: State mutations for account values, authorization, and consensus critical are done in private functions. - -4. Authorize private fun: The private functions which cause mutations also need to be authorized. There are exceptions, but only ones they are deeply nested in other private functions that are authorized. If you accidentally make a private function public, there won't be an issue. - -5. Authorize test helpers: The `#[test_only]` annotations are especially dangerous. If a developer accidentally removes an annotation (or places a line break in the wrong place), then the helper function may be exposed as a public function. Treat test functions as entry points that need to be authorized by `root`. We have seen these errors by the best Move developers, e.g. in Move standard library and vendor code. - -6. Write formal verification `spec`: They don't need to be complicated. Even simple ones will save from a catastrophic deployment. An important pattern is to use them within module code, for example, in `if` flows and `while` loops to check that a condition isn't being met. - -7. Use `assert!` liberally: Functions that only have USER transactions should always abort and return errors for known exceptions. An `assert!` shouldn't prevent you from writing a `spec`, assume you need to do both. Note this does not apply to `root` functions: `assert!` could cause an abort during consensus critical code and that will be fatal. Always use flow control and return early. (There is an exception for genesis of the network in `genesis.move`). - -## Denial of Service Precautions - -# Avoid looping on public calls - -There is an easy vector for DoS related to list looping. When users can increment a list at low cost via a public function you've opened a vector for attack. In those cases there is likely another public function which iterates over that list. If there are cheap calls to both functions, then there is an easy DoS attack. With Move there is an even more dangerous vector: `#[view]` functions are free to call via the REST api. So if it loops over a list, you have basically created a free DoS vector. - -Where this is unavoidable, a rate-limit needs to be placed on caller which increments the list. - -V7 TODO: rate limits. - -# Error Codes - -The Move compiler does the heavy lifting of mapping .move file error codes to usable Rust messages. - -The error code is an integer. And if it is defined by a `constant` with an inline doc comment (`///`), all display errors will include the constant's name and document annotation. See the relevant code in `proof_of_fee.move`: - -``` - //////// ERRORS ///////// - /// Not and active validator - const ENOT_AN_ACTIVE_VALIDATOR: u64 = 1; - /// Bid is above the maximum percentage of the total reward - const EBID_ABOVE_MAX_PCT: u64 = 2; - /// Retracted your bid too many times - const EABOVE_RETRACT_LIMIT: u64 = 3; // Potential update -``` - -An error that is correctly defined in .move source, will yield useful descriptions in CLI and API responses. - -``` -Error: Unknown error Transaction committed on chain, but failed execution: MoveAbort { location: 0000000000000000000000000000000000000000000000000000000000000001::proof_of_fee, c -ode: 131074, info: Some(AbortInfo { reason_name: "EBID_ABOVE_MAX_PCT", description: "Bid is above the maximum percentage of the total reward" }) } -``` - -### NOTE: Integer choice - -Make sure the error code integer is a low integer. While they are defined as `u64` it shouldn't be above 255 (u8), otherwise the error buffer will overflow, and while it won't create an abort, the error code will not be parsed successfully. - -If the error code integer is too high: - -``` - /// Bid is above the maximum percentage of the total reward - const EBID_ABOVE_MAX_PCT: u64 = 20000001; -``` - -The mapping will be lost, and you'll get an integer which will not correspond to anything in the source. - -``` -Error: Unknown error Transaction committed on chain, but failed execution: MoveAbort { location: 0000000000000000000000000000000000000000000000000000000000000001::proof_of_fee, c -ode: 321074, info: None } -``` diff --git a/docs_old/core-devs/move_data_initialization.md b/docs_old/core-devs/move_data_initialization.md deleted file mode 100644 index 8f9d9148..00000000 --- a/docs_old/core-devs/move_data_initialization.md +++ /dev/null @@ -1,61 +0,0 @@ -# Module and Structure Initialization in Move - -When you create a new data structure in Move that needs to be initialized by the system and not by the user, you generally need to add the initialization in two places: - -1. **`genesis.move`**: Add the initialization in the `initialize` function to ensure that the smoke tests execute successfully. -2. **`epoch_boundary.move`**: Add the initialization in the `migrate_data` function to ensure it will be executed in production. - -## Steps for Initialization - -### 1. `genesis.move` - -Add the initialization in the `initialize` function. This is crucial to ensure that smoke tests run without issues. - -Example: - -```move -// In genesis.move -public fun initialize(...) { - // Existing initialization code - ... - // Initialize your module - ::initialize(); - ... -} -``` - -### 2. epoch_boundary.move - -Add the initialization in the `migrate_data` function. This ensures that the initialization is executed in production. - -Example: - -```move -// In epoch_boundary.move -public fun migrate_data(...) { - // Existing migration code - ... - // Initialize your module - ::initialize(); - ... -} -``` - -## Common Issue and Error Message - -One of the side effects of not initializing these data is that when the test scenario uses `LibraSmoke` with more than one node, it will not be able to complete the genesis. If you check the log of one of the nodes, you will see the following error message: - -``` -Execution error InternalError { error: "status UNEXPECTED_ERROR_FROM_KNOWN_MOVE_FUNCTION of type Invariant violation with message [diem_vm] Unexpected error from known Move function, 'block_prologue'. Error: EXECUTION_FAILURE { status_code: MISSING_DATA, sub_status: None, location: 0000000000000000000000000000000000000000000000000000000000000001::... -``` - -This error indicates that the required initialization was not performed, leading to missing data during execution. - -## Summary - -To avoid this issue, always ensure to: - -- Add the necessary initialization in the `initialize` function within `genesis.move`. -- Add the necessary initialization in the `migrate_data` function within `epoch_boundary.move`. - -Following these steps will help you ensure that your module or structure is properly initialized both in testing and production environments. diff --git a/docs_old/core-devs/readme.todo b/docs_old/core-devs/readme.todo deleted file mode 100644 index 483b11d4..00000000 --- a/docs_old/core-devs/readme.todo +++ /dev/null @@ -1,18 +0,0 @@ - -# Table of Contents - -# Basics -[ENG Management Strategy](../about/0_engineering_strategy.md) - -[Sending transactions with CLI] - - -## Core Devs -[Core Dev Quick Start](./core_devs/dev_quick_start.md) - - -[Core Move Coding Conventions](./core_devs/move_coding_conventions.md) - -# Testnet Genesis - -[Genesis](../validators/genesis.md) diff --git a/docs_old/core-devs/smoke_tests.todo b/docs_old/core-devs/smoke_tests.todo deleted file mode 100644 index 60f3b278..00000000 --- a/docs_old/core-devs/smoke_tests.todo +++ /dev/null @@ -1,36 +0,0 @@ - -## Smoke Test Harness -Smoke tests simulate a network by starting a "swarm" of validators locally on the dev machine. The harness: -- simulates a genesis (note this is not the 0L migration genesis, but one tailor made for testing) -- exposes some apis that can manage the swarm (start stop individual nodes). -It provides introspection into the state of each node. -- It also provides bindings to the rust SDK such that transactions can be executed in the VM (by the root account or other accounts). -- It also provides introspection into the account state (of the root or any account). - -## How to write tests -The smoke tests should be located in each module (not in the test harness folder), e.g. (tools/txs). This provides wrapper for other modules to import as a dev_dependency. It produces a default swarm with libra configurations and returns the needed types to run tests. -Don't add functionality tests in this module. The tests here are meta tests to show the harness itself works. Let's keep the dependencies minimal here, to prevent cycling. - -## How to run tests - -### Node Binary -Any tests that depend on `libra-smoke-tests` will require that there is a compiled version of `diem-node` locally. - -For the tests to find the binary's path an environment variable must be set `DIEM_FORGE_NODE_BIN_PATH` - -So either export that variable in the test environment (CI), or run inline with `DIEM_FORGE_NODE_BIN_PATH=path/to/target/release/diem-node` - -### Stack Overflow - -Since the smoke tests can have nested operations, it's possible that a test function could exceed its stack (e.g. `txs smoke_publish()`). At test runtime you can change the stack size with a rust env variable `RUST_MIN_STACK` - -Run with: -``` -RUST_MIN_STACK=104857600 cargo t smoke_publish -``` - -### expected error -If you did not export the variable you will see: -``` -'failed to read env.var. DIEM_FORGE_NODE_BIN_PATH: NotPresent', -``` diff --git a/docs_old/core-devs/testnet_deploy.todo b/docs_old/core-devs/testnet_deploy.todo deleted file mode 100644 index 5f9b2828..00000000 --- a/docs_old/core-devs/testnet_deploy.todo +++ /dev/null @@ -1,239 +0,0 @@ ---- -sidebar_label: 'Deploy' -sidebar_position: 2 -description: 'Deploy Move smart contracts on 0L Network' ---- - - -# Deploy a Hello 0L Contract - - -#### High Level Steps - -1. Write the Contract and Tests -2. Create a TOML file -3. Compile -4. Test -5. Publish -6. Interact - - -### 1. Write the Contract and Tests - -Create the Hello 0L smart contract - -##### Directory Structure - -``` -hello_0L - | - โ”œโ”€โ”€ Move.toml - โ””โ”€โ”€ sources - โ””โ”€โ”€ hello_0L.move - โ””โ”€โ”€ hello_0L_test.move -``` - - - -##### hello_0L.move - -``` -module hello_0L::message { - use std::error; - use std::signer; - use std::string; - use diem_framework::account; - use diem_framework::event; - -//:!:>resource - struct MessageHolder has key { - message: string::String, - message_change_events: event::EventHandle, - } -//<:!:resource - - struct MessageChangeEvent has drop, store { - from_message: string::String, - to_message: string::String, - } - - /// There is no message present - const ENO_MESSAGE: u64 = 0; - - #[view] - public fun get_message(addr: address): string::String acquires MessageHolder { - assert!(exists(addr), error::not_found(ENO_MESSAGE)); - borrow_global(addr).message - } - - public entry fun set_message(account: signer, message: string::String) - acquires MessageHolder { - let account_addr = signer::address_of(&account); - if (!exists(account_addr)) { - move_to(&account, MessageHolder { - message, - message_change_events: account::new_event_handle(&account), - }) - } else { - let old_message_holder = borrow_global_mut(account_addr); - let from_message = old_message_holder.message; - event::emit_event(&mut old_message_holder.message_change_events, MessageChangeEvent { - from_message, - to_message: copy message, - }); - old_message_holder.message = message; - } - } - - #[test(account = @0x1)] - public entry fun sender_can_set_message(account: signer) acquires MessageHolder { - let addr = signer::address_of(&account); - diem_framework::account::create_account_for_test(addr); - set_message(account, string::utf8(b"Hello, Blockchain")); - - assert!( - get_message(addr) == string::utf8(b"Hello, Blockchain"), - ENO_MESSAGE - ); - } -``` - -##### hello_0L_test.move - -``` -#[test_only] -module hello_0L::message_tests { - use std::signer; - use std::unit_test; - use std::vector; - use std::string; - - use hello_0L::message; - - fun get_account(): signer { - vector::pop_back(&mut unit_test::create_signers_for_testing(1)) - } - - #[test] - public entry fun sender_can_set_message() { - let account = get_account(); - let addr = signer::address_of(&account); - diem_framework::account::create_account_for_test(addr); - message::set_message(account, string::utf8(b"Hello, Blockchain")); - - assert!( - message::get_message(addr) == string::utf8(b"Hello, Blockchain"), - 0 - ); - } -} -``` - -### 2. Create a TOML file - -##### Move.toml -:::note -**Named addresses:** -Your module needs to be deployed at an address. You can hard-code the address in the Move.toml file. Or you can have the address variable (e.g. `hello_0L`), defined at publishing time. In either case the address MUST MATCH THE ADDRESS OF THE SIGNER that is publishing. -::: -``` -[package] -name = 'message' -version = '1.0.0' - -# [addresses] -# hello_0L = "_" - -[dependencies.DiemFramework] -git = 'https://github.com/0LNetworkCommunity/diem.git' -rev = 'release' -subdir = 'diem-move/framework/diem-framework' -``` - -### 3. Compile - -``` -libra move compile --package-dir path/to/your/hello_0L_contract - -#Example -libra move compile --package-dir ~/hello_0L --named-addresses "hello_0L=0xd1281de242839fc939745996882c5fc2" -``` - -##### Output -``` -Compiling, may take a little while to download git dependencies... -UPDATING GIT DEPENDENCY https://github.com/0LNetworkCommunity/diem.git -INCLUDING DEPENDENCY DiemFramework -INCLUDING DEPENDENCY DiemStdlib -INCLUDING DEPENDENCY MoveStdlib -BUILDING test_publish -package size 819 bytes -transaction success ยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยท โœ“ -``` - -### 4. Test - - -``` -libra move test --package-dir path/to/your/hello_0L_contract - -# Example -libra move test --package-dir ~/hello_0L --named-addresses "hello_0L=0xd1281de242839fc939745996882c5fc2" -``` - -##### Output -``` -INCLUDING DEPENDENCY DiemFramework -INCLUDING DEPENDENCY DiemStdlib -INCLUDING DEPENDENCY MoveStdlib -BUILDING message -Running Move unit tests -[ PASS ] 0xd1281de242839fc939745996882c5fc2::message_tests::sender_can_set_message -[ PASS ] 0xd1281de242839fc939745996882c5fc2::message::sender_can_set_message -Test result: OK. Total tests: 2; passed: 2; failed: 0 -``` - -### 5. Publish -> Note that `txs publish` will compile the package before submitting. -You should test and compile the code before running, but it is not necessary for publishing. - -``` -libra txs publish --package-dir path/to/your/hello_0L_contract - -#Example -libra txs publish --package-dir ~/hello_0L --named-addresses "hello_0L=0xc208c09ecb52d626ef037c2011ba2d7b18f999eee5be54ac8161627613500c93" -``` - -##### Output -``` -Compiling, may take a little while to download git dependencies... -UPDATING GIT DEPENDENCY https://github.com/0LNetworkCommunity/diem.git -INCLUDING DEPENDENCY DiemFramework -INCLUDING DEPENDENCY DiemStdlib -INCLUDING DEPENDENCY MoveStdlib -BUILDING message -package size 1136 bytes -transaction success ยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยท โœ“ -``` - -### 6. Interact - -#### Interacting with functions -You can interact with your new smart contract with the `generate_transaction` subcommand of the `txs` tool -``` -libra txs generate-transaction --function-id address::module::function - -# Example -libra txs generate-transaction --function-id 0xc208c09ecb52d626ef037c2011ba2d7b18f999eee5be54ac8161627613500c93::message::set_message --args 'b"hello"' -``` - -#### Interacting with view functions -To view the changes you have made use the `resource` subcommand of the `query` tool -``` -libra query resource --account --resource-path-string address::module::struct - -# Example -libra query resource --account 0xc208c09ecb52d626ef037c2011ba2d7b18f999eee5be54ac8161627613500c93 --resource-path-string 0xc208c09ecb52d626ef037c2011ba2d7b18f999eee5be54ac8161627613500c93::message::MessageHolder -``` - -> Be sure to check out Move code examples for various types of Smart Contracts [here](https://github.com/0LNetworkCommunity/diem/tree/release/diem-move/move-examples) \ No newline at end of file diff --git a/docs_old/edit-docs/_category_.json b/docs_old/edit-docs/_category_.json deleted file mode 100644 index faa761d4..00000000 --- a/docs_old/edit-docs/_category_.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "label": "Write Docs", - "position": 10, - "link": { - "type": "generated-index", - "description": "Tooling information for the 0L Network" - } -} diff --git a/docs_old/edit-docs/editing.md b/docs_old/edit-docs/editing.md deleted file mode 100644 index 44bff60d..00000000 --- a/docs_old/edit-docs/editing.md +++ /dev/null @@ -1,82 +0,0 @@ ---- -# BAD: you should not include a `title` field here, instead you should carefully consider the actual header in the document. Notice in this example it is different than the filename. - -# title: "Quick Start" - -# GOOD: if I want a different label in the menu rather than my title (e.g. because it's too long) -# sidebar_label: 'My Title' - -# GOOD: if I want to propose an order to the menu -# sidebar_position: 5 - -# GOOD: shall we hide this page in the menu? -# hidden: true - -# BAD: if you add a description you'll need to maintain it. Better to not use it. -# description: 'Shows this on mouseover' ---- - -# Editing Documents - -## Conventions - -### Filenames -filenames are in "snakecase", lowercase, with underscore for spaces. The file extension should always be `.md`. - -Like this: - `this_is_a_file.md` - -### Metadata -At the top of an `.md` file you may include some metadata which Docusaurus will be able to read and use for parts of the UX (e.g. titles, is it hidden, menu position). - -``` ---- -title: "Menu Title" -sidebar_label: 'My Title' -sidebar_position: 5 -hidden: true -description: 'Shows this on mouseover' ---- -``` -### Titles -There are two ways to set the title in docusaurus. Either set it in the metadata, or put a top level section header `# This Title`. -You should always have a document that begins with a section title. - -##### Don't use metadata -You should not include a `title` field in metadata, instead you should carefully consider the actual header in the document. - -### Menu Labels -The fallback behavior for menu link names will be the filename, e.g.: `this_is_a_file`. -However if your Doc begins with a header title, e.g.: `# My Article`, then the menu label will be exactly that. -To override both cases you can include this item to the metadata: `sidebar_label: Actual Label`. - -#### Images -Do not link externally to images. Place copies of images in the `./docs/assets` folder. - -Then you can link with: -``` -![](../../assets/the-image.png) ` -``` -Note: image names need to follow the same convention. - -## Submit edits - -### A Casual Edit - -Make the change using GitHub directly. You'll need a GitHub account for this. A pull request will be created. - -### Heavy Users -You'll need to fork this `documentation` repo into your own GitHub account. - -#### Get your own repo set up -Create a fork of this repository on your own account, it will look like this: `my-account/documentation`. - -#### Branch -Make a new branch for each major change you are going to make. You'll always branch from your `main`. - -Important: don't make your edits on the `main` branch of your fork. You'll want to keep that one clean, so you can sync from this canonical repo (there's a helpful button on the GitHub interface to do this for you). - -At the end of this you'll have a branch named for example: `some-new-edits`, that lives on `my-account/documentation`. - -##### Submit -Then send that branch as a pull request back to the community's repo. I.e.: the `some-edits` branch of `my-account/documentation`, will then be proposed as a change to `main` of `0LNetworkCommunity/documentation`. diff --git a/docs_old/index.md b/docs_old/index.md deleted file mode 100644 index 7e49691b..00000000 --- a/docs_old/index.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -sidebar_position: 1 ---- - -``` - .:::: .::::::: .:::::::: .::: .:: - .:: .:: .:: .:: .:: .: .:: .:: -.:: .:: .:: .:: .:: .:: .:: .:: -.:: .:: .::::::: .:::::: .:: .:: .:: -.:: .:: .:: .:: .:: .: .:: - .:: .:: .:: .:: .:: .: :: - .:::: .:: .:::::::: .:: .:: - -.:: .:: .:: .:: .::::::: .: -.:: .:: .: .:: .:: .:: .: :: -.:: .:: .: .:: .:: .:: .: .:: -.:: .:: .::: .: .: .:: .:: .:: -.:: .:: .: .:: .:: .:: .:::::: .:: -.:: .:: .: .: .:: .:: .:: .:: -.:::::::: .:: .:::: .:: .:: .:: .:: .:: - -Yes, We Took It ------------------------------------- - -FAQ: https://openlibra.io/faq.html -Wallet: https://github.com/0LNetworkCommunity/carpe -Explorer: https://0l.fyi/ -Docs: https://0lnetwork.dev/ -Papers: https://openlibra.blog -Code: https://github.com/0LNetworkCommunity/libra-framework - -``` diff --git a/docs_old/misc/_category_.json b/docs_old/misc/_category_.json deleted file mode 100644 index 9c036af7..00000000 --- a/docs_old/misc/_category_.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "label": "Transactions", - "position": 2, - "link": { - "type": "generated-index", - "description": "Helpful instructions for submitting transactions" - } -} diff --git a/docs_old/misc/communtiy_wallet_activation.md b/docs_old/misc/communtiy_wallet_activation.md deleted file mode 100644 index 12d5347f..00000000 --- a/docs_old/misc/communtiy_wallet_activation.md +++ /dev/null @@ -1,78 +0,0 @@ -# Community Wallet Activation - -Community Wallet is a qualification an account can receive if it is composed of certain properties. Those properties are: - -- Donor Voice, makes payments with a policy where the donors have observability over the transactions. -- Multisig, accounts can only be manipulated with a multisig policy. -- Ancestry limits, multisig authorities must be a minimum of 3 addresses which are not related by Ancestry. -- Caged, the original authentication key is rotated; similar to resource accounts, but further restricted since they cannot sign arbitrary scripts. - -## Steps - -There are three steps in creating a community wallet account: - -1. **Make it a Donor Voice account and propose the offer to the authorities.** - - This step is atomic. If the proposed authorities do not qualify, the account will not be initialized with Donor Voice features, and the authority offer will not be made. This ensures the community wallet has the expected authorities before proceeding. _Note: The authority offer expires in 7 epochs after this step is executed._ - -2. **The authorities claim the offer over the account.** - - This step ensures that the proposed authorities acknowledge and accept their roles in managing the community wallet, reinforcing the multisig setup security. - -3. **Finalize the account, making it a multisig with the authorities claimed above.** - - This step is irreversible. The current mnemonic will no longer work going forward. The only governance possible is that of the multisig, and any features added (Donor Voice). - -## Using TXS Tool - -To exemplify the usage of the TXS Tool, we will consider Alice (0x1000a), Bob (0x1000b), and Carol (0x1000c) as the ones invited to be the multisig authorities on Dave's (0x1000d) account, which will become the community wallet. - -### Step #1: - -Dave simply provides the list of addresses and the signature threshold. The transaction will be rejected if the proposed accounts do not qualify in the simple sybil resistance ancestry check. - -_Note: this step does not commit the accounts as the authorities, it proposes the authority offer to the address list._ - -``` -libra txs community gov-init -a 0x1000a -a 0x1000b -a 0x1000c -n 2 -``` - -### Step #2: - -Each address owner invited to be an authority in the community wallet must claim the offer by executing this command. - -_Note: this will not make the address a multisig authority yet. After enough addresses claim the offer, the invited authorities need to wait for the donor's final action._ - -``` -libra txs community gov-claim -a 0x1000d -``` - -### Step #3: - -After enough addresses claim the offer, Dave can finalize and cages the account by providing the threshold number. - -``` -libra txs community gov-cage -n 2 -``` - -If the transaction succeeds, Dave's account will finally become a community wallet and a multisig account. Action proposals and votes on the community wallet can then be initiated by the authorities. - -_Note: If an invited authority does not claim the offer and the account is finalized, they will no longer be able to claim the offer. To become an authority after finalization, their addition must be voted on by the existing authorities of the new community wallet._ - -## Intermediate Optional Step: Updating the Authority Offer - -After initializing the community wallet with `gov-init` and before finalizing it with `gov-cage`, the owner has the option to update the authority offer. This allows the owner to change the initial list of proposed authorities if necessary. - -This step also performs the same authority verification as `gov-init`. - -To update the authority offer, the owner can use the following command: - -``` -libra txs community gov-offer -a 0x1000b -a 0x1000c -a 0x1000d -a 0x1000e -n 3 -``` - -In this example, Dave is opting to extend the offer to include Eve (0x1000e) as well. - -If any authority already claimed the offer and remains on the updated list, they do not need to claim again. However, if any authority is removed from the list, even if they had previously claimed, they will not be part of the community wallet authorities when the account is caged by the donor. - -Additionally, this command can be used by the account owner to renew the offer's deadline if it has expired, and the authorities have not yet made their claims. diff --git a/docs_old/misc/genesis_instructions.todo b/docs_old/misc/genesis_instructions.todo deleted file mode 100644 index 1325f2a6..00000000 --- a/docs_old/misc/genesis_instructions.todo +++ /dev/null @@ -1,86 +0,0 @@ - -## Genesis Transaction Instructions -(WIP) - -### Testnet - -1. You'll need an empty repo to be the "coordination" repo for all node registration data. See for example `https://github.com/0o-de-lally/a-genesis` - -1a. You can copy the layout.yaml file. Later you will edit this file with the list of users participating in genesis. - - -2. Configure the nodes - -2a. Nodes will need to have a number of tools installed in order to compile. This script *might* work for your distro `https://github.com/0o-de-lally/libra/blob/main/ol/util/setup.sh` - -``` -# targeting ubuntu -sudo apt update -sudo apt install -y git tmux jq build-essential cmake clang llvm libgmp-dev pkg-config libssl-dev lld - -curl https://sh.rustup.rs -sSf | sh -s -- --default-toolchain stable -y -``` - -3. checkout and build `v7-genesis` - -You'll want to do "release" builds of everything. Grab a cup. - -Pro tip: double check your system installs. If you missed any of the system installs above, you'll be waiting a long time to find out. - -``` -git clone git@github.com:0o-de-lally/libra-v7.git -cd libra-v7 -git checkout release-0.6.9 - -cargo build --release -p libra -p libra-genesis-tools -``` - -4. Get your Github app api token - - -4a. Follow the github instructions: `https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic` - -You'll want to choose the `repo permissions` setting. - -4b You'll need a directory at `$HOME/.libra`. Place your github api token in `github_token.txt` under that directory. - -5. Do the genesis ceremony. -You'll use the wizard for both configuring, registering, and building the genesis transaction. - -You'll input the name of the github repo (`--org-github` and `--name-github `) being used to coordinate. -``` -./target/release/libra-genesis-tools --org-github --name-github register -``` - -6. Coordinator: merge pull requests. - -The owner of the coordinator repo should merge the pull requests the registrants made to the repo. - -7. Run the genesis transaction builder with `libra-genesis-tools genesis` - -You'll use the same github arguments as above plus two more. You'll be using a local copy of the move framework (`--local-framework`). Last, you'll tell the wizard which DB backup file to use to migrate state from the previous network (`--json-legacy`). - -For the legacy JSON you can use the test example: `tools/genesis/tests/fixtures/sample_export_recovery.json` - -``` -./target/release/libra-genesis-tools --org-github --name-github --local-framework --json-legacy genesis -``` - -8. Check your files -You should have a `genesis/genesis.blob` file now in `$HOME/libra` plus a `validator.yaml`. - -9. Start your node! - -``` -libra node --config-path ~/.libra/validator.yaml -``` -### Troubleshooting - -1. I made changes to a .move file - -You'll need to rebuild the framework and its generated code. -``` -cd framework/ -cargo r --release release -# yes two releases in there. -``` diff --git a/docs_old/misc/hot_upgrades.todo b/docs_old/misc/hot_upgrades.todo deleted file mode 100644 index 2a496885..00000000 --- a/docs_old/misc/hot_upgrades.todo +++ /dev/null @@ -1,161 +0,0 @@ - -# Network Hot Upgrades - -## Overview - -The "framework" which contains all the consensus, account, econ policies, etc. for the network is written in Move. This code is stored in the network database, and effectively executed on demand. This means that framework upgrades can occur without redeploying the Move VM itself, or the supporting system code (network node software). It also means the state machine can upgrade without a coordinated halt. - -- To do this we require the `libra` and `libra-framework` cli tools. The command `libra-framework` is used for building the artifacts, and `libra txs` for proposing, voting, and ultimately deploying the artifacts. - -## Historical Upgrade Information and Proposing Upgrades -Historical upgrade information since release 7.0.0 is canonically stored in the [upgrade repository](https://github.com/0LNetworkCommunity/upgrades). To submit an upgrade proposal, you should draft a PR with the relevant information detailing the upgrade using the provided [template](https://github.com/0LNetworkCommunity/upgrades/tree/main/proposals/template) and include the upgrade script packages. - - -## TLDR -- **Fetch the latest release**: `cd libra-framework; git fetch --all; git checkout release-x.x.x` -- **Build framework**: `libra-framework upgrade --output-dir ~/framework_upgrade --framework-local-dir ~/libra-framework/framework/` -- **Propose**: `libra txs governance propose --proposal-script-dir ~/framework_upgrade/1-move-stdlib/ --metadata-url https://github.com/0LNetworkCommunity/upgrades/tree/main/proposals/template` -- **Validators vote**: `libra txs governance vote --proposal-id ` -- **Resolve**: - - 1. `libra txs governance resolve --proposal-script-dir ~/framework_upgrade/1-move-stdlib/ --proposal-id 0` - - 2. `libra txs governance resolve --proposal-script-dir ~/framework_upgrade/2-vendor-stdlib/ --proposal-id 0` - - 3. `libra txs governance resolve --proposal-script-dir ~/framework_upgrade/3-libra-framework/ --proposal-id 0` - -## Upgrade Types: Single and Multiple - -When performing upgrades within the network framework, two primary approaches can be employed: single and multiple module upgrades. The key distinction lies in how these upgrades are proposed, voted on, and executed, particularly with respect to handling multiple modules. - -### Single Framework Upgrade -A single framework upgrade involves updating a singular set of modules within the framework. This process is straightforward and includes the following steps: - -- **Build Framework**: Generate the upgrade Move transaction scripts for the module. -- **Proposal Submission**: Propose the upgrade for the specific framework module. -- **Validator Voting**: Validators within the network vote for or against the proposed upgrade. -- **Achieving Consensus**: The proposal moves forward once it receives support from at least 66% of active validators. -- **Resolution and Deployment**: Resolve the proposal using the exact framework directory that matches the build of the proposed upgrade. This can be done by any validator using the same release branch from the `libra-framework` repository - -### Multiple Framework Upgrades -Multiple framework upgrades require a more nuanced approach, especially regarding resolution stages, to ensure a coherent and secure update across several modules. - -- **Build Framework**: Similar to a single upgrade, start by generating Move transaction scripts for all relevant modules. -- **Proposal for Initial Module**: Propose the upgrade by using the first module (`1-move-stdlib`). This initial proposal is critical as it kickstarts the governance process for the entire upgrade. - -Importantly, the transaction script for upgrading this first module includes a significant addition: **the transaction hash for the subsequent modules** that needs upgrading. These hashes, produced during the artifact building phase, serve as secure identifiers for each module's upgrade script. - -- **Validator Voting**: As with single upgrades, validators vote for or against the proposed upgrade. -- **Achieving Consensus and Sequential Resolution**: Once at least 66% of active validators support the proposal, the initial upgrade can be resolved. -- **Sequential Upgrade Execution**: Execute the resolution process for all involved modules, following the order 1-3. - - -## Upgrade Policy -The diem framework has information in the metadata that controls the policy that a publisher can set for upgrading their modules. These are: -- Arbitrary(0): Allows code upgrades without compatibility checks, for non-shared packages. -- Compatible(1): Requires compatibility checks to ensure no breaking changes in public functions or resource layouts. -- Immutable(2): Prevents any upgrades, ensuring the permanence of critical code. - -Due to some circumstances, a publisher may want to downgrade the policy to allow changes to go through that a restrictive policy would not allow. We can do this by building the framework with a flag(`--danger-force-upgrade`) that sets the upgrade policy as Aribitrary - -Example - -``` -libra txs governance propose --proposal-script-dir ~/framework_upgrade/3-libra-framework/ --metadata-url https://www.github.com/0LNetworkCommunity/UpdateProposalTemplate --danger-force-upgrade -``` - -## Procedure - -We will use this guide to do a multi-step upgrade as this is the most common upgrade that is done. - -### Build Artifacts - -##### 1. Build the upgrade Move transaction scripts - -This will be a Move package which is machine-generated for a one-time execution. It contains bytecode which will be allowed to be executed (by anyone), once there is a vote and agreement on the proposal passing. The on-chain execution is guarded with a hash of this transaction, which the proposer provides in the proposal transaction (in advance of the vote). - -An upgrade script that is tampered with will yield a different execution hash, and will be prevented from running (it is likely to be blocked by the transaction size limits before entering the mempool). - -The `libra-framework upgrade` command will produce a newly compiled Move upgrade transaction script, its binary, and the hash. - -You need to provide: -- `--output-dir`: this directory the upgrade transaction files should be saved to. A new folder called `framework_upgrade` will be created under the output-dir path. - -- `--framework-local-dir`: the source code for the framework so that the transaction script can import it as a dependency. - -Optionally you could provide the flag `--danger-force-upgrade - -``` -# Note the paths -libra-framework upgrade --output-dir --framework-local-dir - -# Example -libra-framework upgrade --output-dir ~/framework_upgrade --framework-local-dir ~/libra-framework/framework/ -``` -:::note -This creates 3 seperate library upgrade script directories -- 1-move-stdlib -- 2-vendor-stdlib -- 3-libra-framework - -You will choose depending on which library you want updated -::: - -All the artifacts are now created, the proposal transaction can be submitted. But it's a good idea to document this on github first. - -##### 2. Share the output artifacts on Github. - -Create a new repository with the outputted directory. Add a README.md file. - -The proposer can add the link to this Github repo in the proposal phase. - - -### Upgrade Ceremony - -##### 3. With `txs` anyone (no authority needed) can submit the proposal and metadata. You'll need to provide the actual script compiled path, and an optional URL which contains documentation of the proposal (e.g github). - -``` -# note the actual script dir -libra txs governance propose --proposal-script-dir --metadata-url - -# Example -libra txs governance propose --proposal-script-dir ~/framework_upgrade/1-move-stdlib/ --metadata-url https://www.github.com/0LNetworkCommunity/UpdateProposalTemplate - -``` -If this transaction succeeds it will produce a proposal id, which is a number. Now the proposal is open to voting. - -:::note -You can query the next proposal using this command: ` libra query view --function-id 0x1::diem_governance::get_next_governance_proposal_id` -::: - -##### 4. With `libra txs` anyone with governance authority (the epoch's validators as of `V7`), can submit a vote in favor (or against it with `--should-fail`). - -We assume the default is to vote in favor. To vote "approve" simply: -``` -libra txs governance vote --proposal-id -``` - -If voter would like the proposal to be rejected: -``` -libra txs governance vote --proposal-id --should-fail -``` -:::note -You can query to see the for and against votes using this command: ` libra query view --function-id 0x1::diem_governance::get_votes --args ` -::: - -After everyone has voted (to reach the consensus threshold of 66% as of `V7`), the proposal will be in a "Resolvable" state. Anyone can resolve it by submitting the upgrade transaction. This means the sender must have the source transaction script for the upgrade (step #1 above). - -##### 6. Use `txs` to resolve a successfully approved proposal -``` -# Note the actual path -libra txs governance resolve --proposal-script-dir --proposal-id - -# Example - 1. libra txs governance resolve --proposal-script-dir ~/framework_upgrade/1-move-stdlib/ --proposal-id 0 - - 2. libra txs governance resolve --proposal-script-dir ~/framework_upgrade/2-vendor-stdlib/ --proposal-id 0 - - 3. libra txs governance resolve --proposal-script-dir ~/framework_upgrade/3-libra-framework/ --proposal-id 0 -``` - -If this transaction is successful the new bytecode will be written to the VM diff --git a/docs_old/misc/key_rotation.todo b/docs_old/misc/key_rotation.todo deleted file mode 100644 index 4529f8c0..00000000 --- a/docs_old/misc/key_rotation.todo +++ /dev/null @@ -1,93 +0,0 @@ -# Key Rotation -> CAUTION: Please read carefully and ensure you understand these instructions. Rotating the wrong key could lock you out of your account and make funds permanently inaccessible. - -There are two cases: - -1) You are in full control of an account and would like to rotate to a new private key (using a new mnemonic). - -This is a single step, and you can simply use the current mnemonic to sign a transaction and the new mnemonic to sign a rotation proof. - -2) You are claiming an account from someone else. - -This requires two steps where the current owner (Alice) will first authorize an existing account of the new owner (Bob) to rotate keys for the account being claimed. Bob will have two accounts at the end of the process, and the prior owner, Alice, will have none. - -## CASE 1: Rotate Keys on Your Wallet - -You will be prompted for a mnemonic twice. But these should be DIFFERENT mnemonics. - -The first mnemonic is for your current credentials which will be deprecated. It is used to sign and send the rotation transaction to the blockchain. - -In the process, you will be prompted for the NEW mnemonic you would like to be using going forward. - -Additionally, you can expect the CLI tool to ask you to confirm this operation twice in the process. - -```bash -libra txs user rotate-key -``` - -Note: If you have an advanced case and would like to submit the private key itself, see below. - -## CASE 2: Claim an account - -There are two steps involved in claiming another account. First, some definitions: -- There are two parties Original Owner (Alice, for example) and New Owner (Bob). - -- Alice is offering the Claimed Account (`0x123`) to Bob. - -- Bob must already have a separate Delegate Account on-chain (`0x456`). The only reason for this is that Bob needs to do some sensitive signing of keys and submit it to the chain, and there's no way for Alice or really anyone else to do this for him. - -- Bob will also require a New Mnemonic, which he will use to control the Claimed Account in the future. - -With all that in place: - -#### Original Owner Alice's Job - -Alice will send a transaction to "delegate" Bob's account `0x456` with the power to rotate the keys to `0x123`. - -Alice's job ends here. - -#### New Owner Bob's Job - -Next, Bob needs his usual credentials for `0x456`, and also the New Mnemonic he plans to use for `0x123`. - -He submits a transaction (after a bit of processing of the New Mnemonic private keys), which should successfully rotate the keys to `0x123`. - -The job of the Delegate account `0x456` is over (the account could even be disposed of). - -## Step 1: Original Owner Delegates Rotation Capability -Grant another user the capability to change the Authentication Key for a specified address. You will be prompted to enter the mnemonic for the address whose authentication key will be changed: - -```bash -libra txs user rotation-capability --delegate-address -``` - -The specified delegate address can now rotate authentication keys on the address for which the mnemonic was provided. - -## Step 2: New Owner Rotates Authentication Keys Using the Delegated Address -Enables a delegated user to rotate the Authentication Key for a specified wallet address: - -```bash -libra txs user rotate-key --claim-address -``` - -# Cheat Sheet - -### Create a new mnemonic -``` -libra wallet keygen -``` - -# Advanced: Optionally Input the Private Key -To recover a private key using a mnemonic, use: - -```bash -libra wallet keygen --mnemonic --output-dir -``` - -Your private key will be stored in a file called `private_keys.yaml` in the directory you specified above. Specifically, it's called `account_private_key`. The private key corresponds with the `account_address` above it. - -Once you have a private key, you can submit the transaction by explicitly setting the key. In this case, the new mnemonic will not be asked for. - -```bash -libra txs user rotate-key --new-private-key --claim-address -``` \ No newline at end of file diff --git a/docs_old/misc/sybil_resistance.todo b/docs_old/misc/sybil_resistance.todo deleted file mode 100644 index 4c4e19ff..00000000 --- a/docs_old/misc/sybil_resistance.todo +++ /dev/null @@ -1,128 +0,0 @@ ---- -sidebar_position: 2 -sidebar_label: '0L Sybil Resistance' -description: "0L's innovation is mechanism design" ---- -# 0L Sybil Resistance ---- -_PoF and musical chairs attempt to minimize (not eliminate) the surface area for governance: of negotiating setting inflation rate, rewards rate, validator set size, and voting in/out members of validator set._ - -In the context of the Libra framework, the integration of Proof of Fee (PoF), Musical Chairs methods, and the Reward Thermostat mechanism addresses the common issue of networks overpaying for security. PoF optimizes validator selection based on bids, balancing experienced and new participants, which aids in cost-effective security management. The Reward Thermostat further enhances this model by dynamically adjusting validator rewards based on bidding patterns, reducing rewards when bids are consistently low and increasing them when bids are high, thus maintaining economic sustainability. Musical Chairs contributes by dynamically adjusting the validator set size based on actual network performance, preventing the unnecessary expansion of the set and contributing to cost efficiency. This holistic approach, in line with the Libra framework, aims to achieve robust security without excessive costs, ensuring a more efficient and economically sustainable blockchain ecosystem. Operating under the principle of equal voting power per validator, PoF, Musical Chairs, and the Reward Thermostat together offer a balanced, performance-oriented framework for blockchain networks. - -## TL;DR: Process ---- - -### Algorithm Steps for Proof of Fee (PoF) and Musical Chairs - -#### Proof of Fee (PoF) - -1. **Bid Submission:** - - Validators submit their bids for the auction process. - -2. **Bid Evaluation:** - - Bids are ordered and evaluated based on the amount. - -3. **Validator Selection:** - - Top bidders are selected until all available seats are filled. - - Maintain a 2/3 majority of proven validators from the previous epoch. - -4. **Jail Reputation Check:** - - Assess validatorsโ€™ jail records for reliability. - -5. **Finalization:** - - Confirm the final list of validators. - - Determine the lowest accepted bid and set it as the fee for all. - -6. **Reward Thermostat Adjustment:** - - Dynamically adjust the rewards for validators based on the network's bidding behavior. - - Decrease rewards if bids are consistently low, suggesting the reward is overly generous. - - Increase rewards if bids are consistently high, indicating the reward is not enticing enough. - -#### Musical Chairs - -1. **Performance Monitoring:** - - Track and evaluate validatorsโ€™ performance metrics. - -2. **Set Size Adjustment:** - - If 100% compliance, increase validator set size by one. - - If less than 5% failure, maintain current size. - - If more than 5% failure, reduce size to the number of compliant validators. - -3. **Validator Assessment:** - - Review validatorsโ€™ performance for the current epoch. - -4. **Selection for Next Epoch:** - - Based on performance, determine validators for the next epoch. - -5. **Adaptation:** - - Adjust the algorithm parameters based on overall network health and performance. - -## Proof of Fee (POF) ---- -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 sybil resistance 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 and rewards. - -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/) - -### Reward Thermostat - -The Reward Thermostat in the 0L Network's Proof of Fee (PoF) system functions by adjusting the validator rewards in response to their bidding patterns. It decreases rewards when bids are consistently low, indicating that the rewards are more than adequate, and increases them when bids are high, suggesting that the current rewards might not be sufficiently motivating for validators. This adaptive mechanism maintains economic sustainability and aligns validator incentives with the network's ongoing performance and stability. - -Incorporating the Reward Thermostat into the PoF system involves specific steps to adjust validator rewards in response to their bidding behavior: - -1. **Monitor Bidding Behavior:** - - The system analyzes bid percentages over a set number of epochs. It looks at the average bid percentage over the past 5 or 10 epochs. - -2. **Adjust Rewards Based on Bid Levels:** - - If bids are consistently low (e.g., below a 50% threshold for several epochs), this suggests that the current rewards are overly generous. In response, the system decreases rewards. A typical reduction might be by 5% for a short trend or 10% for a longer trend. - - Conversely, if bids are consistently high (e.g., above a 95% threshold for several epochs), indicating that rewards are not enticing enough, the system also decreases rewards. This reduction could also be by 5% or 10%, depending on the duration of the trend. - -3. **Implement Reward Changes:** - - These adjustments are applied to the baseline reward. For example, if the baseline reward is 1,000 tokens and a 5% decrease is triggered, the new reward would be 950 tokens. - -4. **Feedback Loop for Continuous Adjustment:** - - The system continuously monitors bidding behavior and makes adjustments in each epoch, ensuring that the rewards remain aligned with validator motivations and the network's economic conditions. - -This mechanism ensures that rewards are neither too generous nor too unattractive, maintaining a balance that encourages efficient network operation while aligning with validators' economic incentives. - - -## Musical Chairs ---- - -The Libra Framework features an innovative algorithm known as "Musical Chairs" to dynamically determine the optimal number of validators. This approach diverges from traditional fixed-capacity models in blockchain networks, offering a more flexible and performance-based system. - -In Musical Chairs, the size of the validator set is not static but fluctuates based on the real-time performance of the network. This method relies on a set of specific performance metrics to assess the efficiency and compliance of validators. The process ensures that the network remains robust, secure, and efficient without being overburdened by an unnecessarily large number of validators. - -Further insights into this novel mechanism can be explored in PoF publications - - -## Vouching ---- - -There is also a distinctive "vouching" system that is intricately woven into its sybil resistance mechanism. This system plays a pivotal role in establishing and maintaining the network's integrity and security, complementing the Proof of Fee (PoF) and Musical Chairs models. Vouching in the 0L Network is designed to effectively navigate and utilize the trust graph, making it a cornerstone of the network's overall governance and functionality. - -Vouching is primarily applied in the context of validators however it could be utilized in other places within the network in the future. In this system, each validator is required to secure vouches from two existing validators who must come from distinct ancestry trees. This means that the endorsing validators cannot be part of the same lineage or hierarchical chain of account creation, ensuring a broad and diverse base of trust. - -The vouching process is governed by specific rules to ensure its effectiveness and integrity: - -- **Expiration of Vouches:** Each vouch is designed with a finite lifespan, expiring after 90 epochs. This temporal limitation necessitates active and ongoing participation in the network's trust-building processes. - -- **Economic Aspect:** Obtaining a vouch incurs a cost of 1000 microlibra. Rather than functioning as a mere fee, this amount is burned. This signifies a substantial commitment on the part of the voucher and adds a layer of economic deterrence against insincere or inauthentic vouching. - -## Examples ---- -### Examples of Validators Not Entering the Set - -- **High Bid Scenario:** - - All bids from validators are significantly higher than the network's threshold, leading to a situation where there aren't enough seats for all high bidders. This can happen if the validators overestimate the required bid amount. - -- **Limited Seat Availability:** - - The number of available seats is less than the number of validators willing to participate. In such cases, even validators with reasonably high bids might not get selected. - -- **Performance-Based Exclusion in Musical Chairs:** - - A validator who fails to meet the performance standards set by the network (e.g., uptime, block validation success rate) may be excluded from the next epoch's validator set, regardless of their bid in the PoF process. - -- **Failure to Meet Qualification Criteria:** - - Validators not meeting essential criteria such as sufficient funds, minimum vouches, or having a history of being jailed in the previous round, will be excluded regardless of their bid. - diff --git a/docs_old/misc/tool_design.todo b/docs_old/misc/tool_design.todo deleted file mode 100644 index 33291b4b..00000000 --- a/docs_old/misc/tool_design.todo +++ /dev/null @@ -1,20 +0,0 @@ - -## About Libra Tool Design -The tools are intended to be minimalist, yet modular. Upstream vendors have sophisticated and complex tooling. This is usually unwieldy for the profile of typical 0L users. - -### The Customer -If you have a typical end-user use case, Carpe will likely be all you need. -These tools are for users which are engaged in more admin level operations on the network: configuring and querying contracts. - -For that user the cli tools here will like have sufficient features: query, transact, run node. - -Similarly if you are a Move dev, similarly the most common features are covered: testing, verifying, compiling, deploying. - -### Bring your own tool -If you have needs that aren't met with these tools, all of them are also exported as libraries. Meaning: they are architected so that they are easy to extend. - -#### Start a new minimal Rust crate -With a simple Rust project, that uses Clap as a CLI scaffold, you can import all of the CLI types, whole or in part. This means you can extend the existing methods (by creating a `trait` extension in your own tool). - -Additionally the most relevant vendor SDK types are re-exported by `libra-types`. So you should be able to take advantage of much of the Move resource parsing (e.g converting account addresses from API calls to structs); - diff --git a/docs_old/misc/validator_registration.todo b/docs_old/misc/validator_registration.todo deleted file mode 100644 index 47bcd0ef..00000000 --- a/docs_old/misc/validator_registration.todo +++ /dev/null @@ -1,73 +0,0 @@ -# Welcome Validators - -This assumes you have the `libra` cli installed in your local $PATH. - -## Quick start -``` -# create account keys -libra wallet keygen - -# create the validator config files on your node -libra config validator-init - -# a friend will onboard the account if it doesn't yet exist on chain - -# send validator info -libra txs validator register - -# get vouches from existing validators (just ask) -libra txs validator vouch --vouch-for - -# submit a bid to be in the validator set -libra txs validator pof --bid-pct --expiry - -``` - -# Get Keys -If you don't already have an account, you'll need a mnemonic (seed), to generate all keys. - -``` -libra wallet keygen -``` - -# Initialize validator files - -Follow the prompts here. Your node needs to have keys generated using a mnemonic from step #1. - -``` -libra config validator-init -``` - -# Get the account on chain -Someone needs to create that account onchain first. -Ask someone to deposit a coin to your accout from step #1 - -``` -# friend sends one coin to your account which creates it -libra txs transfer -t -a 1 - -``` - -# Submit configs to chain - -``` -libra txs validator register - -# optionally pass -f to the file where operator.yaml from step #2 above is located -libra txs validator register -f /path/to/foo/operator.yaml - -``` - -# Get Vouches -0L uses very light reputation games to keep the validator set trusted. -Just ask an existing validator for a vouch. It doesn't cost you anything and it needs no stake. - -Your friend will: -`libra txs validator vouch --vouch-for ` - -# Bid to be in the validator set -0L uses Proof-of-Fee for sybil resistance, instead of Proof-of-Stake. You don't need any stake to join, but you just need to be able to bid on how much you are willing to pay to be in the validator set. The cheapest bid proposed by validators will be actually what all validators pay (uniform price auction). - -``` -libra txs validator pof --bid-pct --expiry -``` diff --git a/docs_old/validators/_category_.json b/docs_old/validators/_category_.json deleted file mode 100644 index a9e6a6bc..00000000 --- a/docs_old/validators/_category_.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "label": "Validators", - "position": 5, - "link": { - "type": "generated-index", - "description": "Information for Validators of the 0L Network" - } -} \ No newline at end of file diff --git a/docs_old/validators/detailed_instructions.todo b/docs_old/validators/detailed_instructions.todo deleted file mode 100644 index c8a87518..00000000 --- a/docs_old/validators/detailed_instructions.todo +++ /dev/null @@ -1,182 +0,0 @@ ---- -title: "Running a Validator" -sidebar_label: 'Running a Validator' -sidebar_position: 3 ---- - -# Running a Validator - -### Requirements -- TWO unix hosts, one for Validator Node, and one for the Private Fullnode ("VFN"). -libra code targets Ubuntu 22.04. -- Recommended specs: - - Validator: 300GB SSD harddrive, 8 core CPU, 16G RAM - - VFN: 100G storage, 8 core CPU, 16G RAM -- Separate static IP addresses for the machines, or appropriate DNS mapping. - -### Firewall -:::note -During testnet and devnet operation, you will likely open port `8080` on your Validator to allow outside access to the RPC endpoint, which is an API that runs as part of the libra service. -VFNs and public fullnodes should by default serve port `8080` RPC for operability. -::: - -#### Validator - -The following ports must be open: `6180`, `6181` - -- `6180` should be open on all interfacess `0.0.0.0/0`, it's for consensus and uses noise encryption. -- `6181` is for the private validator fullnode network ("VFN"), the firewall should only allow the IP of the fullnode to access this port. - -#### VFN -:::note -This node does not serve transactions and does not participate in consensus, it relays data out of the validator node, and transactions into the validator. -::: - -The following ports must be open: `6181`, `6182`, `8080` - -- `6181` is for the private validator fullnode network ("VFN"), it should only allow traffic from the Validator node IP address above. -- `6182` is for the the PUBLIC fullnode network. This is how the public nodes that will be serving JSON-RPC on the network will receive data and submit transactions to the network. -- `8080` is the RPC port and we suggest VFNs and public fullnodes to serve this port by default for operability. - - -## Setting up a Validator - -These instructions target Ubuntu. - -1.1. Set up an Ubuntu host with `ssh` access, e.g. in a cloud service provider. - -1.2. Associate a static IP with your host, this will be tied to you account. This address will be shared on the chain, so that other nodes will be able to find you through the peer discovery mechanism. - -1.3. Libra binaries should be run in a linux user that has very narrow permissions. Before you can create binaries you'll need some tools installed probably by `sudo` and likely in root. - -1.4. Use `tmux` to persist the terminal session for build, as well as for running the nodes and tower app. Also this setup requires `git` and `make`, which might be installed already on your host. If not, perform the following steps now: - -```bash -sudo apt update -sudo apt install -y git tmux jq build-essential cmake clang llvm libgmp-dev pkg-config libssl-dev lld libpq-dev -``` - - -1.5. Install Rust - -```bash -curl https://sh.rustup.rs -sSf | sh -s -- --default-toolchain stable -y - -# restart your bash instance to pickup the cargo paths -source ~/.bashrc -``` - - -### Create Binaries - -It is recommended to perform the steps from 1.7 onwards inside tmux. Short tmux instruction: - -1.6 Start a new [tmux](#tmux-basics) session - -```bash -# start a new tmux session -tmux new -t libra-setup -``` - - -1.7 Clone this repo: -``` -git clone https://github.com/0LNetworkCommunity/libra-framework -cd ~/libra-framework -``` -1.8 Build the source and install binaries: -This takes a while, ensure your are still inside the `tmux` session to avoid your session gets disconnected. - -```bash -cargo build --release -p libra -``` - - -1.9 Making the `libra` binary globally executable and persistent - -:::note -This assumes the `libra` binary is already built and located at `~/libra-framework/target/release/libra`. -::: -``` -# Copy libra binaries to cargo bins path -sudo cp -f ~/libra-framework/target/release/libra* ~/.cargo/bin/ - -# Check libra execution and version -libra version -``` - - - -### You will now need [sync your validator to the latest block](/validators/restore) and [register your validator](/validators/register). - -#### Start Node - -`libra node --config-path ~/.libra/validator.yaml` - -### Setup as a service(optional) - - -**Install Service** -:::note -use can this service template instead of running in tmux -::: -`sudo nano /lib/systemd/system/libra-node.service` - - -#### Systemd template - -``` -[Unit] -Description=Libra Node Service - -[Service] -User=nodeuser -Group=nodeuser - -LimitNPROC=1048576 -LimitNOFILE=1048576 - -#Environment="RUST_LOG=warn" -WorkingDirectory=/home/nodeuser/.libra -ExecStart=/home/nodeuser/libra-framework/target/release/libra node --config-path /home/nodeuser/.libra/validator.yaml - -Restart=on-failure -RestartSec=3s - -StandardOutput=journal -StandardError=journal -SyslogIdentifier=libra-node - -[Install] -WantedBy=multi-user.target -Alias=libra-node.service - -# config the service and start -sudo systemctl enable libra-node -sudo systemctl start libra-node -``` - -**Reload and start system service** - -`sudo systemctl daemon-reload` - -`sudo systemctl enable libra-node` - -`sudo systemctl start libra-node` - -**Check the service is operating correctly** - -`sudo systemctl status libra-node` - - - -### TMUX basics - -1. New session: `tmux new -t ` -2. Detach from Session: press Ctrl-b and then d -3. rejoin unnamed session, if only one session exists: `tmux a` -4. rejoin unnamed session by id: `tmux ls` to get the ID and then `tmux a -t ` -5. rejoin named session: `tmux a -t ` -6. kill session: attach to the session --> press Ctrl-b, then type `:kill-session` and press ENTER - ---- diff --git a/docs_old/validators/genesis.todo b/docs_old/validators/genesis.todo deleted file mode 100644 index ceb5f978..00000000 --- a/docs_old/validators/genesis.todo +++ /dev/null @@ -1,279 +0,0 @@ ---- -sidebar_position: 5 -sidebar_label: "Genesis Ceremony" -description: 'Launch the 0L Network' ---- - -# Genesis Ceremony - -This guide outlines the essential steps for conducting a Genesis Ceremony in the 0L Network. - -## The Purpose of the Genesis Ceremony - -A Genesis Ceremony is a pivotal event marking the creation of the network's genesis block โ€” the foundational block that -underpins the entire blockchain. -The genesis of a network can begin with a blank state (0 balances) or with preserving the state of an earlier chain and -migrate to the new chain during the genesis ceremony. The latter approach is also known as a fork. -It is a crucial process that not only initiates the network but also involves migrating the network's state from an -earlier version to the next version. - -Follow this document to navigate the process effectively, ensuring a smooth and successful launch or upgrade of the 0L -Network. - -## High Level Ceremony Steps - -1. Operator Name & Cleanup -2. Static IP & Open Ports -3. Fetch Source & Verify Commit Hash -4. Build `libra-framework` Packages -5. Account Preparation and Adding GitHub PAT -6. Pre-Genesis Registration - - **Stop**: Wait for the coordinator to merge all PR's. Step 8 can be done while you wait -7. PR Received -8. PR Merged -9. Build JSON_Legacy -10. All Nodes Added to `layout.yaml` Users Key - - **Wait for the Coordinator**: Wait for the coordinator post-pre-genesis set closure and to add all genesis participants. -11. Pull from Genesis Repo and Build - - **Wait for the Coordinator**: Wait for the coordinator's signal to start. -12. Start Nodes! - -Coordination happens via the 0L Discord server voice channels, and a Google Sheet will track participants at each. Each -step requires careful attention to the coordinator's instructions. - -:::note -Only proceed with asynchronous steps after the coordinator confirms the previous sequential blocking steps as completed. -::: - - -## Genesis Ceremony Steps - -### 1. Operator name and cleanup of previous binaries or testnet data - -Provide your operator name (handle) in the **[Genesis Worksheet](https://docs.google.com/spreadsheets/d/19hZTqGeN1cVw0Jlj5vWtMSEB36EYftjdSfPHhgwCiy8/edit#gid=1604681690).** - -If you have participated in testnets, delete any previous forks of testnet repos (such as `release-v6.9.0-rc.0-genesis-2`) from your GitHub repositories. - -Previous clones and testnets leave data in the `.libra` directory, clean those up by removing these directories - -``` bash -rm -rf ~/libra-framework && rm -rf ~/.libra/libra-legacy-v6 -rm -rf ~/.libra/data && rm -rf ~/.libra/genesis && rm -rf ~/.libra/secure-data.json -rm -f /usr/bin/libra && rm -rf /usr/local/bin/libra && rm -f ~/.cargo/bin/libra -``` - - -### 2. Get your static IP and open necessary ports - -Fetch your external Static IP and set it aside -``` bash -curl -s ipinfo.io | jq .ip -``` - -The validator should have the following ports open: `6180`, `6181` - -- `6180` should be open on all interfaces `0.0.0.0/0`, it's for consensus and uses noise encryption. -- `6181` is for the private validator fullnode network ("VFN"), the firewall should only allow the IP of the fullnode to access this port. - - -### 3. Fetch source & verify commit hash - -We suggest you start a new tmux session -``` bash -sudo apt install tmux -y -tmux new -t libra-node -``` - -Clone the `libra-framework` repository and make sure you are on the correct branch -``` bash -cd ~ -git clone https://github.com/0LNetworkCommunity/libra-framework -cd ~/libra-framework -git fetch --all && git checkout release-6.9.0-rc.10 -``` - -Ensure the commit hash matches your peers and the coordinator -``` bash -git log -n 1 --pretty=format:"%H" -``` - -- **Confirm the git hash in the [Genesis Worksheet](https://docs.google.com/spreadsheets/d/19hZTqGeN1cVw0Jlj5vWtMSEB36EYftjdSfPHhgwCiy8/edit#gid=1604681690).** - - -### 4. Build and install the libra binaries - -To use many of our genesis CLI tooling, we have to switch to its directory -``` bash -cd ~/libra-framework/tools/genesis -``` - -If your directory structure setup is different from the default, you can override the defaults by exporting the following environment variables: `SOURCE_PATH`, `BINS_PATH`, `DATA_PATH`. See the [Makefile](https://github.com/0LNetworkCommunity/libra-framework/blob/03d9f10bb539bda4c3f9de96e4a411971ec88d80/tools/genesis/Makefile#L7) for more details. - -Install the source and reload bash -``` bash -sudo apt install make -y -EPOCH=692 make install && source ~/.bashrc -``` - -- **Confirm with "done" in the [Genesis Worksheet](https://docs.google.com/spreadsheets/d/19hZTqGeN1cVw0Jlj5vWtMSEB36EYftjdSfPHhgwCiy8/edit#gid=1604681690).** - - -### 5. Account Preparation and Adding GitHub PAT (use classic with repo privileges) - -Acquire [GitHub Personal Access Token (PAT)](https://github.com/settings/tokens) with repo privileges. Paste it aside. - -If you are new and do not have an account, create one, carefully record your seed phrase, and keep it aside for later -``` bash -libra wallet keygen -``` - -Setup the validator configs and data directory `~/.libra` (it is OK to refresh your configs) -``` bash -libra config validator-init -``` - -Retrieve Validator address and paste it aside -``` bash -grep 'account_address' ~/.libra/public-keys.yaml -``` - -Paste your GitHub PAT in the `~/.libra/github_token.txt` file -``` bash -nano ~/.libra/github_token.txt -``` - -- **Enter your Validator Address Static IP in the [Genesis Worksheet](https://docs.google.com/spreadsheets/d/19hZTqGeN1cVw0Jlj5vWtMSEB36EYftjdSfPHhgwCiy8/edit#gid=1604681690).** - - -### 6. Export genesis ceremony repository and register for genesis - -Export the genesis ceremony repository as an environment variable -``` bash -export GIT_REPO=release-v6.9.0-genesis-registration -``` - -Register for genesis -``` bash -make register -``` - -- **Confirm with "done" in the [Genesis Worksheet](https://docs.google.com/spreadsheets/d/19hZTqGeN1cVw0Jlj5vWtMSEB36EYftjdSfPHhgwCiy8/edit#gid=1604681690).** - -:::warning -Please wait for the coordinator at this step. -::: - - -### 7. PR Received - -(coordinator confirms) - - -### 8. PR Merged - -(coordinator merges your PR) - - -### 9. Build JSON_Legacy from snapshot and ancestry - -Build the legacy json -``` bash -make legacy -``` - -- **Confirm `v5_recovery.json` md5 hash in the [Genesis Worksheet](https://docs.google.com/spreadsheets/d/19hZTqGeN1cVw0Jlj5vWtMSEB36EYftjdSfPHhgwCiy8/edit#gid=1604681690).** - - -### 10. All nodes added to `layout.yaml` users key - -:::warning -Please wait for the coordinator. Pre-genesis set closes here. -::: - - -### 11. Make Genesis - -Pull from the genesis repo and build genesis -``` bash -make genesis -``` - -- Confirm with "done" in the **[Genesis Worksheet](https://docs.google.com/spreadsheets/d/19hZTqGeN1cVw0Jlj5vWtMSEB36EYftjdSfPHhgwCiy8/edit#gid=1604681690).** - -:::warning -Please wait for the coordinator. -::: - - -### 12. Start nodes! - -Wait for the coordinator, say a prayer, then start! -``` bash -libra node -``` - -To disconnect from your tmux session `CTRL + b` and then `d` to disconnect. To reconnect you can use `tmux a -t libra-node`. - -You could also consider running `libra node` as a service [which is detailed here](detailed-instructions#setup-as-a-serviceoptional). - - ---- -**End Of The Genesis Ceremony Steps.** - - -### Migration Math - -#### `--target-supply ` Change in denomination (split) - -To adjust the count of coins, and how they get split, the genesis command offers -one input: `--target-supply`. - -If for example the supply will scale (pro-rata) from 2,000,000 to 100,000,000, -then the genesis supply calculator (`set_ratios_from_settings()`) will create a split of 50 re-denominated coins -for 1 coin. Coins do not change name, no changes in ownership, and all policies -remain the same. - -#### `--years-escrow ` Provision an infrastructure escrow - -If the validators will set aside rewards for future validators this is done -with: `--years-escrow`. If for example this argument is used, the supply -calculator (`set_ratios_from_settings()`) will take the *remainder* of the -`--target-future-uses` which isn't already in a community-wallet. - -#### `--target-future-uses ` Community wallet and infra escrow target percentage of network supply -This parameter affects the expected funds available for infra-escrow pledges, -and the daily epoch reward budget. - -Note: this could have been implemented as a number targeting the infra-escrow percentage -(e.g. `target-infra-escrow`). However the user-experience of the validator at -genesis is more difficult in this case since the community wallet numbers are -not easily calculated in advance (it would require multiple steps with this tool). - -We calculate the infra-escrow budget by working backwards from one input the -community would already have: a target for "future users" (versus end-user -accounts). -If for example the community expected that the combined infra-escrow and -community wallets will represent 70% of the network as a target, we deduce that -infra-escrow will be the remainder of `((0.70 * total supply) - (sum of community -wallets))`. - -A lower amount of `--target-future-uses` means a lower amount available to -infrastructure escrow pledges to use over the time `--years-escrow`. i.e. if -target future uses is 55% (`--target-future-uses 0.55`) and the community -wallet balance is 45%, then there is -10% of supply to be spread over 7 years (`--years-escrow 7`). - -Note also we derive the baseline -daily validator rewards from those two parameters. In the example above the -daily reward baseline equals `(10% * Total -Supply) / 7 (years) * 100 validators (baseline) * 365 (days)` - -Troubleshooting. If the target percent % is below the proportion of the sum of community -accounts the program will exit with error. - - -#### `--map_dd_to_slow `. Adjusting the future-uses calculator - -Usually in test-cases, there may be cases that the future-uses calculator gets -skewed because certain accounts are not in the expected state (a community -wallet wasn't expected to exist at that point). diff --git a/docs_old/validators/getting_started.todo b/docs_old/validators/getting_started.todo deleted file mode 100644 index fee65d97..00000000 --- a/docs_old/validators/getting_started.todo +++ /dev/null @@ -1,74 +0,0 @@ ---- -sidebar_label: 'Getting Started' -sidebar_position: 1 -description: 'Learn whats involved running a validator on 0L Network' ---- -# Getting Started ---- - -## Validators - -Participating as a validator on the 0L Network is an open and permissionless process, accessible to all. The community is supportive and eager to assist those passionate about contributing to the network's security. However, it's important to note that this role comes with certain responsibilities, as outlined below, along with corresponding rewards for the efforts made. - -### Validator Operations - -#### Key Responsibilities -1. **Continuous Operation**: Validators must ensure their systems are operational 24/7. -2. **Technical Expertise**: A background in System Administration and DevOps is essential for those looking to become Validators. -3. **Network Maintenance**: Validators play a critical role in maintaining the network's integrity and are responsible for proposing blocks within the Libra network.. - -### Selection Process -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. - -#### High-Level Steps for Validator Selection - -1. **Bidding Process**: Prospective validators submit their bids during the Proof of Fee (PoF) auction for a specified number of epochs. -2. **Epoch Transition and Seat Availability**: - - At each epoch change, the number of available seats for validators is determined. This depends on factors such as network performance, interest level among validators, and the number of epochs the network has been operational. -3. **Seat Allocation**: - - Seats are allocated starting from the highest bid to the lowest, until either all the validators are included or all the seats are filled. -4. **Payment by Selected Validators**: - - Validators who are chosen in the set pay an amount equal to the lowest bid within that set. -5. **Repetition of Process**: - - This selection and bidding process is repeated at the beginning of each new epoch. - -### Compliance Requirements for Validators - -#### Overview -To participate in the bidding process for the next epoch, validators must -maintain compliance. Non-compliant validators at the time of an epoch change -will be [jailed](../cli-tools/txs/validator.md) and must be -un-jailed by one of the active validators to re-enter the process. - -#### Detailed Compliance Criteria - -1. **For New Entrants**: - - Obtain 2 [vouches](../cli-tools/txs/validator.md#manage-vouching-operations) from existing validators, ensuring no shared ancestry. - - Submit a bid that ranks among the highest in comparison to others, relative to the number of available validator seats. Essentially, the bid should be sufficiently competitive to fall within the range of top bids for the given number of validator seats. - -2. **For Existing Epoch Validators**: - - Fulfill all requirements applicable to new entrants. - - Ensure the number of successfully proposed blocks exceeds the number of failed blocks. - -#### Further Insights -For an in-depth exploration of these guidelines and their underlying principles, refer to the comprehensive discussions in these papers: [Proof of Fee Part 1](https://0l.network/2022/10/15/proof-of-fee-part-1/) and [Proof of Fee Part 2: A Proposal](https://0l.network/2022/10/20/proof-of-fee-part-2-a-proposal/). - -### Validator Rewards Structure - -#### Reward Distribution -Validators demonstrating high performance are awarded at the conclusion of each epoch, approximately every 24 hours. The source of these rewards is the [Infrastructure Ecosystem Pledge](https://0l.network/2022/10/11/proposal-2210-8-infrastructure-escrow-funding/), established following the network's upgrade from version 5 to version 6.9.0. This fund was primarily contributed to by both current and former validators, as well as the wider community. - -#### Fund Origin and Decision Making -Details on the formation of this fund and the associated decision-making process are outlined in the [Arctika Recommendation](https://0l.network/2023/05/23/team-arctika-recommendation/). The establishment of the reward amount per epoch and the basis of the fund itself were influenced by several key factors: - - A projected reward sustainability (or "runway") of approximately 10 years. - - Setting reward amounts comparable to prevailing industry standards, assuming the network achieves a valuation close to $100 million. - -These measures aim to incentivize consistent and effective network performance by validators, aligning with broader industry norms and long-term network health. - - -### How to become a Validator -1. [Configure and setup your machine](/validators/detailed-instructions) -2. [Sync Database to the current version](/validators/restore) -3. [Register your Validator](/validators/register) diff --git a/docs_old/validators/hot_upgrades.todo b/docs_old/validators/hot_upgrades.todo deleted file mode 100644 index 383e1f43..00000000 --- a/docs_old/validators/hot_upgrades.todo +++ /dev/null @@ -1,169 +0,0 @@ ---- -sidebar_position: 9 -sidebar_label: 'Hot Upgrades' -description: 'Upgrading Framework Libraries' ---- - - - -# Network Hot Upgrades - -## Overview - -The "framework" which contains all the consensus, account, econ policies, etc. for the network is written in Move. This code is stored in the network database, and effectively executed on demand. This means that framework upgrades can occur without redeploying the Move VM itself, or the supporting system code (network node software). It also means the state machine can upgrade without a coordinated halt. - -- To do this we require the `libra` and `libra-framework` cli tools. The command `libra-framework` is used for building the artifacts, and `libra txs` for proposing, voting, and ultimately deploying the artifacts. - - -## Historical Upgrade Information and Proposing Upgrades -Historical upgrade information since release 7.0.0 is canonically stored in the [upgrade repository](https://github.com/0LNetworkCommunity/upgrades). To submit an upgrade proposal, you should draft a PR with the relevant information detailing the upgrade using the provided [template](https://github.com/0LNetworkCommunity/upgrades/tree/main/proposals/template) and include the upgrade script packages. - - -## TLDR -- **Fetch the latest release**: `cd libra-framework; git fetch --all; git checkout release-x.x.x` -- **Build framework**: `libra-framework upgrade --output-dir ~/framework_upgrade --framework-local-dir ~/libra-framework/framework/` -- **Propose**: `libra txs governance propose --proposal-script-dir ~/framework_upgrade/1-move-stdlib/ --metadata-url https://github.com/0LNetworkCommunity/upgrades/tree/main/proposals/template` -- **Validators vote**: `libra txs governance vote --proposal-id ` -- **Resolve**: - - 1. `libra txs governance resolve --proposal-script-dir ~/framework_upgrade/1-move-stdlib/ --proposal-id 0` - - 2. `libra txs governance resolve --proposal-script-dir ~/framework_upgrade/2-vendor-stdlib/ --proposal-id 0` - - 3. `libra txs governance resolve --proposal-script-dir ~/framework_upgrade/3-libra-framework/ --proposal-id 0` - -## Upgrade Types: Single and Multiple - -When performing upgrades within the network framework, two primary approaches can be employed: single and multiple module upgrades. The key distinction lies in how these upgrades are proposed, voted on, and executed, particularly with respect to handling multiple modules. - -### Single Framework Upgrade -A single framework upgrade involves updating a singular set of modules within the framework. This process is straightforward and includes the following steps: - -- **Build Framework**: Generate the upgrade Move transaction scripts for the module. -- **Proposal Submission**: Propose the upgrade for the specific framework module. -- **Validator Voting**: Validators within the network vote for or against the proposed upgrade. -- **Achieving Consensus**: The proposal moves forward once it receives support from at least 66% of active validators. -- **Resolution and Deployment**: Resolve the proposal using the exact framework directory that matches the build of the proposed upgrade. This can be done by any validator using the same release branch from the `libra-framework` repository - -### Multiple Framework Upgrades -Multiple framework upgrades require a more nuanced approach, especially regarding resolution stages, to ensure a coherent and secure update across several modules. - -- **Build Framework**: Similar to a single upgrade, start by generating Move transaction scripts for all relevant modules. -- **Proposal for Initial Module**: Propose the upgrade by using the first module (`1-move-stdlib`). This initial proposal is critical as it kickstarts the governance process for the entire upgrade. - - Importantly, the transaction script for upgrading this first module includes a significant addition: **the transaction hash for the subsequent modules** that needs upgrading. These hashes, produced during the artifact building phase, serve as secure identifiers for each module's upgrade script. - -- **Validator Voting**: As with single upgrades, validators vote for or against the proposed upgrade. -- **Achieving Consensus and Sequential Resolution**: Once at least 66% of active validators support the proposal, the initial upgrade can be resolved. -- **Sequential Upgrade Execution**: Execute the resolution process for all involved modules, following the order 1-3. - - -## Upgrade Policy -The diem framework has information in the metadata that controls the policy that a publisher can set for upgrading their modules. These are: -- Arbitrary(0): Allows code upgrades without compatibility checks, for non-shared packages. -- Compatible(1): Requires compatibility checks to ensure no breaking changes in public functions or resource layouts. -- Immutable(2): Prevents any upgrades, ensuring the permanence of critical code. - -Due to some circumstances, a publisher may want to downgrade the policy to allow changes to go through that a restrictive policy would not allow. We can do this by building the framework with a flag(`--danger-force-upgrade`) that sets the upgrade policy as Aribitrary - -Example - -``` -libra txs governance propose --proposal-script-dir ~/framework_upgrade/3-libra-framework/ --metadata-url https://www.github.com/0LNetworkCommunity/UpdateProposalTemplate --danger-force-upgrade -``` - -## Procedure - -We will use this guide to do a multi-step upgrade as this is the most common upgrade that is done. - -### Build Artifacts - -##### 1. Build the upgrade Move transaction scripts - -This will be a Move package which is machine-generated for a one-time execution. It contains bytecode which will be allowed to be executed (by anyone), once there is a vote and agreement on the proposal passing. The on-chain execution is guarded with a hash of this transaction, which the proposer provides in the proposal transaction (in advance of the vote). - -An upgrade script that is tampered with will yield a different execution hash, and will be prevented from running (it is likely to be blocked by the transaction size limits before entering the mempool). - -The `libra-framework upgrade` command will produce a newly compiled Move upgrade transaction script, its binary, and the hash. - -You need to provide: -- `--output-dir`: this directory the upgrade transaction files should be saved to. A new folder called `framework_upgrade` will be created under the output-dir path. - -- `--framework-local-dir`: the source code for the framework so that the transaction script can import it as a dependency. - -Optionally you could provide the flag `--danger-force-upgrade - -``` -# Note the paths -libra-framework upgrade --output-dir --framework-local-dir - -# Example -libra-framework upgrade --output-dir ~/framework_upgrade --framework-local-dir ~/libra-framework/framework/ -``` -:::note -This creates 3 seperate library upgrade script directories -- 1-move-stdlib -- 2-vendor-stdlib -- 3-libra-framework - -You will choose depending on which library you want updated -::: - -All the artifacts are now created, the proposal transaction can be submitted. But it's a good idea to document this on github first. - -##### 2. Share the output artifacts on Github. - -Create a new repository with the outputted directory. Add a README.md file. - -The proposer can add the link to this Github repo in the proposal phase. - - -### Upgrade Ceremony - -##### 3. With `txs` anyone (no authority needed) can submit the proposal and metadata. You'll need to provide the actual script compiled path, and an optional URL which contains documentation of the proposal (e.g github). - -``` -# note the actual script dir -libra txs governance propose --proposal-script-dir --metadata-url - -# Example -libra txs governance propose --proposal-script-dir ~/framework_upgrade/1-move-stdlib/ --metadata-url https://www.github.com/0LNetworkCommunity/UpdateProposalTemplate - -``` -If this transaction succeeds it will produce a proposal id, which is a number. Now the proposal is open to voting. - -:::note -You can query the next proposal using this command: ` libra query view --function-id 0x1::diem_governance::get_next_governance_proposal_id` -::: - -##### 4. With `libra txs` anyone with governance authority (the epoch's validators as of `V7`), can submit a vote in favor (or against it with `--should-fail`). - -We assume the default is to vote in favor. To vote "approve" simply: -``` -libra txs governance vote --proposal-id -``` - -If voter would like the proposal to be rejected: -``` -libra txs governance vote --proposal-id --should-fail -``` -:::note -You can query to see the for and against votes using this command: ` libra query view --function-id 0x1::diem_governance::get_votes --args ` -::: - -After everyone has voted (to reach the consensus threshold of 66% as of `V7`), the proposal will be in a "Resolvable" state. Anyone can resolve it by submitting the upgrade transaction. This means the sender must have the source transaction script for the upgrade (step #1 above). - -##### 6. Use `txs` to resolve a successfully approved proposal -``` -# Note the actual path -libra txs governance resolve --proposal-script-dir --proposal-id - -# Example - 1. libra txs governance resolve --proposal-script-dir ~/framework_upgrade/1-move-stdlib/ --proposal-id 0 - - 2. libra txs governance resolve --proposal-script-dir ~/framework_upgrade/2-vendor-stdlib/ --proposal-id 0 - - 3. libra txs governance resolve --proposal-script-dir ~/framework_upgrade/3-libra-framework/ --proposal-id 0 -``` - -If this transaction is successful the new bytecode will be written to the VM diff --git a/docs_old/validators/register.todo b/docs_old/validators/register.todo deleted file mode 100644 index 7c839081..00000000 --- a/docs_old/validators/register.todo +++ /dev/null @@ -1,155 +0,0 @@ ---- -sidebar_position: 6 -sidebar_label: 'Post-Genesis Ceremony Registration' -description: 'Register a Validator on the 0L Network' ---- - -# Register a Validator on the 0L Network - -Welcome! - -## Quick outline of all the steps -``` bash -# Checkout the source -git clone https://github.com/0LNetworkCommunity/libra-framework - -# Install dependencies and Rust lang -cd ~/libra-framework -bash ./util/dev_setup.sh -t - -# restart your bash instance to pickup the cargo paths -source ~/.bashrc - -# build and install the binary -cd ~/libra-framework -cargo build --release -p libra - -# Make the release path global and persistent -sudo cp -f ~/libra-framework/target/release/libra* ~/.cargo/bin/ - -# Check libra execution and version -libra --version - -# ----------------------- -# Using libra CLI to generate a new account and register - -# create account keys -libra wallet keygen - -# create the validator config files on your node -# you will need to update vfn values to match validator values. see script below -# you will also need to set the libra.yaml to point to testnet -libra config validator-init - -# Set your client `libra.yaml` with the rpc-load-balancer upstream node -libra config fix --force-url https://rpc.openlibra.space:8080 - -# a friend will onboard the account if it doesn't yet exist on chain. It is done by sending coins to an account -libra txs transfer --to-account --amount 1 - -# send validator info -libra txs validator register - -# get vouches from existing validators (just ask) -libra txs validator vouch --vouch-for - -# submit a bid to be in the validator set -libra txs validator pof --bid-pct --expiry - -# run as a fullnode and switch to the validator mode once entered the set, check the detailed instructions below the page. -``` - -## Detailed instructions - -### Generate a new account - Get Keys -If you don't already have an account, you will need a mnemonic (seed), to generate all keys. - -``` bash -libra wallet keygen -``` - -### Initialize validator files - -Follow the prompts here. Your node needs to have keys generated using a mnemonic from step #1. - -``` bash -libra config validator-init -``` - - -- You will need to use this script to make the VFN match your validator node values. -``` bash -cat << 'EOF' > fix_vfn_values.sh -#!/bin/bash - -# Extract the value from validator_network_public_key -validator_key=$(sed -n 's/^validator_network_public_key: "\(.*\)"/\1/p' ~/.libra/operator.yaml) - -# Use the extracted value to replace full_node_network_public_key -sed -i "s/^full_node_network_public_key: .*/full_node_network_public_key: \"$validator_key\"/" ~/.libra/operator.yaml - -# File path -file="$HOME/.libra/operator.yaml" - -# Extract the host and port from validator_host -host=$(awk '/^ host:/{print $0}' "$file") -port=$(awk '/^ port:/{print $0}' "$file") - -# Replace full_node_host: ~ with full_node_host: and add host and port -sed -i "/^full_node_host: ~/c\\ -full_node_host:\\n$host\\n$port" "$file" -EOF - -chmod +x fix_vfn_values.sh -./fix_vfn_values.sh -``` - -### Get the account on chain -Someone needs to create that account onchain first. -Ask someone to deposit a coin to your account from step #1 - -``` bash -# friend sends one coin to your account which creates it -libra txs transfer -t -a 1 -``` - -### Update upstream node -Set your client `libra.yaml` with the rpc-load-balancer upstream node -``` bash -libra config fix --force-url https://rpc.openlibra.space:8080 -``` - -### Submit configs to chain - -``` bash -# Submit your account on chain, which takes the default location to your ~/.libra/operator.yaml -libra txs validator register - -# Or you can use the -f option to provide the exact path to your operator.yaml file -libra txs validator register -f ~/.libra/operator.yaml -``` - - -### Get Vouches -0L Network uses very light reputation games to keep the validator set trusted. -Just ask an existing validator for a vouch. It helps a lot if you share your node specs and a little bit of your experience with them. - -Your friend will: -``` bash -libra txs validator vouch --vouch-for -``` - -### Bid to be in the validator set -0L Network uses Proof-of-Fee for sybil resistance, instead of Proof-of-Stake. You don't need any stake to join, but you just need to be able to bid on how much you are willing to pay to be in the validator set. The cheapest bid proposed by validators will be actually what all validators pay (uniform price auction). -``` bash -libra txs validator pof --bid-pct --expiry -``` - -### Run the node as fullnode and then validator mode -- Once your validator enters the set you will need to stop running as a fullnode and run as a validator. Until then, you can: - - use the following instructions to: [sync database to the current state](/validators/restore) and run as a fullnode. -- When your node is in the active set, it is time to change your node config path to point to the `validator.yaml`. -- Stop your node and run in the validator mode: -``` bash -libra node --config-path ~/.libra/validator.yaml -``` diff --git a/docs_old/validators/rescue.todo b/docs_old/validators/rescue.todo deleted file mode 100644 index 2939f6b6..00000000 --- a/docs_old/validators/rescue.todo +++ /dev/null @@ -1,29 +0,0 @@ -# Rescue Missions - -## TL;DR -The same tools used to manufacture on-chain governance proposals -(`libra-framework`) are used to create governance scripts. -These scripts can be executed offline with db-bootstrapper via the `rescue-cli` -tool here. - -# Framework upgrades -For now you need to craft a frankenstein TX by hand. A better tool could be -built, but a rescue operation is a rare occurrence and should be led by people -familiar with the tools. - -Creating the bytes for publishing a new/updated Move module is done by the -libra-framework tool; -simply `cargo run upgrade`. You can see the instructions there to -create new Move module compile artifacts. - -See an example in the test fixtures here. -This is one specific case of of an upgrade while a network is halted. We have -copied the bits from upgrade examples in -`framework/src/upgrade_fixtures/fixtures/upgrade-multi-lib/3-libra-framework/sources/3-libra-framework.move` -this file will include a test module: `all_your_base.move` - -# HACK THE BLACK MAGIC -When trying to bootstrap a db, and get a valid state transition, we need the transaction to emit a "reconfiguration event": -a reconfiguration event must: -- happen with timestamp not equal to previous reconfiguration -- have a "touch" to validator set, whatever that means diff --git a/docs_old/validators/restore.todo b/docs_old/validators/restore.todo deleted file mode 100644 index 8d844063..00000000 --- a/docs_old/validators/restore.todo +++ /dev/null @@ -1,84 +0,0 @@ ---- -sidebar_position: 4 -sidebar_label: "Restore" -description: 'Restore and sync the 0L Network database to the current state' ---- - -# Restore - -Restore the 0L Network database to get up-to-date with the current state of the network. The `epoch-archive-mainnet` [repository](https://github.com/0LNetworkCommunity/epoch-archive-mainnet) contains other useful commands that are out of the scope of this tutorial but are easily accessible in the readme file of the repository and its `Makefile`. - -### Prerequisites -:::note -You will need an account and libra configuration to use this tool. If you don't have an account yet, you can use the following command to create one. ***Make sure to store your mnemonics!*** -``` bash -libra wallet keygen -``` -::: - -### Initialize configs -Currently, you need to sync as a full node. To do that you need to initialize `fullnode.yaml` in `~/.libra/fullnode.yaml`. Use the following command to generate the `fullnode.yaml` file: - -``` bash -libra config fullnode-init -``` - -### Update upstream node -Set your client `libra.yaml` with the rpc-load-balancer upstream node -``` bash -libra config fix --force-url https://rpc.openlibra.space:8080 -``` - -### Clone and build the epoch-archive-mainnet repository - -``` bash -cd ~ -git clone https://github.com/0LNetworkCommunity/epoch-archive-mainnet -cd ~/epoch-archive-mainnet -make bins -``` - -### Sync as a Fullnode -:::warning -You will need to open port `6182` -::: - -#### Get the latest state of the chain -``` bash -make restore-all -``` - -#### Start as a fullnode (or vfn or validator node depending on your need) -The following example starts the node as a fullnode by providing the `fullnode.yaml` as its config option: -``` bash -libra node --config-path ~/.libra/fullnode.yaml -``` - -#### Verify -You can check that you are syncing by checking that your `ledger_version` and `block_height` are increasing via the API endpoint -``` bash -watch 'curl localhost:8080/v1/ | jq' -``` - -**Response example:** -``` json -{ - "chain_id": 2, - "epoch": "700", - "ledger_version": "3322278", - "oldest_ledger_version": "3316234", - "ledger_timestamp": "1699327458805056", - "node_role": "full_node", - "oldest_block_height": "1581950", - "block_height": "1584970", - "git_hash": "bafac94d6edd39d972729db21156d47758eb8969" -} -``` - -### How to clean the database and sync to the latest state again? - -The following instructions will remove your existing `~/.libra/data/db/` directory and also update the `epoch-archive.yaml` file with the latest waypoint. You can study the `Makefile` in the `epoch-archive-mainnet` [repository](https://github.com/0LNetworkCommunity/epoch-archive-mainnet) to fine-tune and understand its instructions better. -``` bash -cd ~/epoch-archive-mainnet -make wipe-db && make restore-all -``` diff --git a/docs_old/validators/validator_quickstart.todo b/docs_old/validators/validator_quickstart.todo deleted file mode 100644 index ab58c73e..00000000 --- a/docs_old/validators/validator_quickstart.todo +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "Validator Quickstart" -sidebar_label: 'Validator Quickstart' -sidebar_position: 2 ---- - -## Quick Start - -On an Ubuntu 22.04 host: - -``` bash -# We suggest you run the following in a tmux session from your user home directory -tmux a -cd ~ - -# Checkout the source -git clone https://github.com/0LNetworkCommunity/libra-framework - -# Install dependencies and Rust lang -cd ~/libra-framework -bash ./util/dev_setup.sh -t - -# build and install the binary -cd ~/libra-framework -cargo build --release -p libra - -# Copy libra binaries to cargo bins path -sudo cp -f ~/libra-framework/target/release/libra* ~/.cargo/bin/ - -# Check libra execution and version -libra version -``` - -For a more detailed rundown see [here](/validators/detailed-instructions) diff --git a/docs_old/validators/vfn_setup.todo b/docs_old/validators/vfn_setup.todo deleted file mode 100644 index 8365d1bf..00000000 --- a/docs_old/validators/vfn_setup.todo +++ /dev/null @@ -1,158 +0,0 @@ ---- -title: "VFN Setup" -sidebar_label: 'VFN' -sidebar_position: 7 ---- - - -## VFN Setup - -Note: -We strongly suggest that all validators also run a VFN, which is a node that serves as crucial counterpart to completing the design of our network. The VFN is how the public network is able to reach the validator, which should not be done directly. - - -## Ports -The following ports must be open: `6181`, `6182`, `8080`. - -- `6181` is for the private validator fullnode network ("VFN"), it should only allow traffic from the Validator node IP address above. -- `6182` is for the the PUBLIC fullnode network. This is how the public nodes that will be serving JSON-RPC on the network will receive data and submit transactions to the network. -- `8080` is the RPC port and we suggest VFNs and public fullnodes to serve this port by default for operability. - - -### Cleanup - -Previous clones and testnets leave data in the `.libra` directory, clean those up by removing these directories - -``` bash -rm -rf ~/libra-framework -rm -rf ~/.libra/data && rm -rf ~/.libra/genesis && rm -rf ~/.libra/secure-data.json -rm -f /usr/bin/libra && rm -rf /usr/local/bin/libra && rm -f ~/.cargo/bin/libra -``` - -Clone libra-framework and build -``` bash -cd ~ -git clone https://github.com/0LNetworkCommunity/libra-framework - -cd ~/libra-framework -bash ./util/dev_setup.sh -bt -. ~/.bashrc - -cd ~/libra-framework -cargo build --release -p libra -p diem-db-tool -p diem -``` - -Make sure your path to libra is global and persistent -``` bash -sudo cp -f ~/libra-framework/target/release/libra* ~/.cargo/bin/ -``` - - -### VFN initialization -Initialize `~/.libra` config directory -``` bash -libra config init -``` - -Grab the **genesis blob** and **waypoint** (creates `fullnode.yaml` not used here) -``` bash -libra config fullnode-init -``` - -:::warning -Until a patch is published to pull correctly from the `epoch-archive-mainnet` repo, the `genesis.blob` and `waypoint.txt` will be wrong if you are using `libra config fullnode-init`. -In order to fix this, after you have run the above command, please run: -- `wget https://raw.githubusercontent.com/0LNetworkCommunity/epoch-archive-mainnet/main/upgrades/v6.9.0/genesis.blob -O ~/.libra/genesis/genesis.blob` -- `wget https://raw.githubusercontent.com/0LNetworkCommunity/epoch-archive-mainnet/main/upgrades/v6.9.0/waypoint.txt -O ~/.libra/genesis/waypoint.txt` -::: - -Set your client `libra.yaml` with the rpc-load-balancer upstream node -``` bash -libra config fix --force-url https://rpc.openlibra.space:8080 -``` - -:::info -If you notice problems getting transactions through, or when the RPC Load Balancer is down, you can adjust the url to `"http://localhost:8080/"` in `~/.libra/libra.yaml` -::: - -Configure your VFN using the validator config tool -``` bash -libra config validator-init --vfn -``` - -:::warning -Due to a bug currently in `libra config validator-init`, please run this command again without the `--vfn` parameter -::: - -The VFN config will then be automatically created here -``` bash -cat ~/.libra/vfn.yaml -``` - - -This is what your VFN `full_node_networks` section should look like: -``` yaml -full_node_networks: -- network_id: - private: 'vfn' - discovery_method: 'onchain' - listen_address: '/ip4/0.0.0.0/tcp/6181' - seeds: - : - addresses: - - '/ip4//tcp/6181/noise-ik/<0x_your_validator_publickey>/handshake/0' - role: 'Validator' -- network_id: 'public' - discovery_method: 'onchain' - listen_address: '/ip4/0.0.0.0/tcp/6182' - identity: - type: 'from_file' - path: '/home//.libra/validator-full-node-identity.yaml' -``` - -Note: -Your VFN will use your validator as an upstream without an identity, while the public network will use the identity file. - -### Issue the On-Chain Configuration - -From your VFN, take note of the public IPv4 address -``` bash -curl ipinfo.io -``` - -Take note of your `full_node_network_public_key` -``` bash -grep full_node_network_public_key ~/.libra/public-keys.yaml - -# example: full_node_network_public_key: "0x_full_node_network_public_key" -``` - -On both machines, the config in `operator.yaml` should be complete with separate Validator and VFN keys and IPs -``` yaml -validator_network_public_key: "0xthiswasalreadysetpublickey" -validator_host: - host: - port: 6180 -full_node_network_public_key: "0x_full_node_network_public_key" -full_node_host: - host: - port: 6182 -``` - -On your Validator, update the on-chain config for the VN/VFN (do this just once) -``` bash -libra txs validator update - -Enter your 0L mnemonic: -๐Ÿ”‘ -transaction success ยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยทยท โœ“ -``` - -Wait (up until one epoch) and then check the on-chain values to confirm -``` bash -libra query val-config 0xabc4321yourvalidatoraccount | jq -``` - -### Run the VFN -In a tmux, run the following command: -`libra node --config-path ~/.libra/vfn.yaml` diff --git a/docs_old/validators/with_docker_setup.todo b/docs_old/validators/with_docker_setup.todo deleted file mode 100644 index 4b061515..00000000 --- a/docs_old/validators/with_docker_setup.todo +++ /dev/null @@ -1,373 +0,0 @@ ---- -title: "Running a fullnode/vfn/validator node with docker" -sidebar_position: 8 -sidebar_label: 'Docker setup' -description: 'Running a fullnode/vfn/validator node with docker' ---- - -:::danger WIP -This page is a work in progress. -Tread carefully. -::: - - -The canonical way of running the standard 0L setup, is to have two machines, one for the validator node, and one for the fullnode that acts as the gateway of the validator to the world (see [VFN here](/validators/vfn-setup)). - -This page describes how to setup a node with docker, which provides a convenient way to hit the ground running without managing packages and installation on the host machine. - -In addition, a validator can take an advantage of this configuration and run both the validator node and the VFN on the same machine. This would require a second network interface with a new IPv4 address. See further details below. - - - -## Prerequisites - -_This guide would not cover those_ - -- Ubuntu 22.04 -- Docker -- docker compose -- sudo access - - - -## Build the libra node docker image (both for single or double IPv4) - -Place this Dockerfile somewhere in your system (~/workspace/SOME_NAME/Dockerfile): - -```bash -# Dockerfile - -# Use Debian 11 image as the base for the build stage -FROM debian:11 as build - -# Set the PATH environment variable to include the Rust Cargo bin directory -ENV PATH="/root/.cargo/bin:${PATH}" - -# Install system dependencies required for building the project -# These include compilers, development tools, libraries, and other utilities -RUN apt-get update -y -q && apt-get install -y -q \ - build-essential \ - curl \ - cmake \ - clang \ - git \ - libgmp3-dev \ - libssl-dev \ - llvm \ - lld \ - pkg-config \ - ca-certificates \ - update-ca-certificates \ - && rm -rf /var/lib/apt/lists/* - - -# Install Rust using rustup and set the default toolchain to stable -RUN curl https://sh.rustup.rs -sSf | sh -s -- --default-toolchain stable -y - -# Install Rust packages with Cargo -RUN cargo install toml-cli # Command-line tool to manipulate TOML files -RUN cargo install sccache # Shared Compilation Cache to speed up recompiles - -# Arguments that can be overridden at build time -ARG REPO=https://github.com/0LNetworkCommunity/libra-framework.git -ARG BRANCH=main - -# Set the working directory to /root -WORKDIR /root - -# Clone the specified branch or release tag from the given repository -RUN echo "Checking out '${BRANCH}' from '${REPO}' ..." \ - && git clone ${REPO} \ - && cd libra-framework \ - && git fetch --all && git checkout ${BRANCH} \ - && echo "Commit hash: $(git rev-parse HEAD)" - -# Set the working directory to the cloned repository -WORKDIR /root/libra-framework - -# Build the specified Rust packages as release binaries -RUN cargo build --release \ - -p libra \ - -p libra-genesis-tools \ - -p libra-txs \ - -p diem-db-tool - -# Start a new, final image to reduce size using Debian 11 slim variant -FROM debian:11-slim as production - -# Copy the built binaries from the 'build' stage to the 'production' image -COPY --from=build [ \ - "/root/libra-framework/target/release/libra", \ - "/root/libra-framework/target/release/libra-genesis-tools", \ - "/root/libra-framework/target/release/libra-txs", \ - "/root/libra-framework/target/release/diem-db-tool", \ - "/usr/local/bin/"] - -``` - -In the same folder you placed the Dockerfile, run the following commands to build the image -```bash -docker build -t openlibra:main . -``` - -This will take several minutes, depends on your machine. A community image might be available in the future from docker hub. There is a value also in building your own image and not relying on a centralized image. - -Ensure image was built successfully -```bash -docker images | grep openlibra - -openlibra main b64dbca39f51 9 minutes ago 153MB -``` - -## Single IP setup - -### Create the docker-compose file - -Place the following docker-compose.yaml file in the same folder as the Dockerfile: - -```bash -# docker-compose.yaml - -########## Defaults ############# -x-defaults: &defaults - image: "openlibra:main" - restart: "on-failure" - pid: host - ulimits: - nproc: 500000 - nofile: 500000 - volumes: - - "node_data:/root/.libra" - -x-util-defaults: &util-defaults - <<: *defaults - restart: "no" - command: [ "tail", "-f", "/dev/null" ] - -version: "3.8" -services: - ########## Main services ############# - - fullnode: - <<: *defaults - container_name: "0l-fullnode" - cpuset: "0" - command: - [ - "libra", - "node", - "--config-path", - "/root/.libra/fullnode.yaml" - ] - ports: - - "6180:6180" - - "6181:6181" - - "6182:6182" - - "8080:8080" - - "9101:9101" - - validator: - <<: *defaults - container_name: "0l-validator" - cpuset: "0" - command: - [ - "libra", - "node", - "--config-path", - "/root/.libra/validator.yaml" - ] - ports: - - "6180:6180" - - "6181:6181" - - "6182:6182" - - "8080:8080" - - "9101:9101" - - vfn: - <<: *defaults - container_name: "0l-vfn" - cpuset: "0" - command: - [ - "libra", - "node", - "--config-path", - "/root/.libra/vfn.yaml" - ] - ports: - - "6180:6180" - - "6181:6181" - - "6182:6182" - - "8080:8080" - - "9101:9101" - - tower: # needs mnemonic injection - <<: *defaults - container_name: "0l-tower" - cpuset: "1" - stdin_open: true - tty: true - command: - [ - "libra", - "tower", - "start", - ] - - shell: - <<: *util-defaults - container_name: 0l-shell - -volumes: - node_data: - driver: local - driver_opts: - type: none - o: bind - device: "~/.libra" - -``` - - -### Ensure your configuration files are in place. - -Depends on which service you wish to run (fullnode/validator/vfn), you'd need to place the relevant yaml files in the `~/.libra` folder. - -Run the following commands based on your needs: -```bash -libra config fullnode-init - -# or - -libra config validator-init - -# or - -libra config validator-init --vfn - -``` - -Note that you'd need to replace your user home path in the template default `data_dir`, and the `genesis_file_location` to point to `/root/.libra/...rest_of_path_unchanged` - -Here is an example of modified `fullnode.yaml` relevant entries: -```bash -... - -base: - data_dir: '/root/.libra/data' - -execution: - genesis_file_location: '/root/.libra/genesis/genesis.blob' -... -``` - -Start the desired service with `docker compose` - -```bash -docker compose up -d fullnode - -# or - -docker compose up -d validator - -# or vfn or tower, etc. -``` - -Ensure the node is running by examining the updated `ledger_version` over few seconds - -```bash -watch 'curl localhost:8080/v1/ | jq' -``` - -Or check the container logs -```bash -docker compose logs -f --tail 50 fullnode - -# or replace fullnode with validator or vfn -``` - -:::warning If the version is 0 or you're having connectvitiy issues -Do the manual DB restore as described in the [Restore section](/validators/restore#clone-and-build-the-epoch-archive-mainnet-repository) and then [clean and sync](/validators/restore#how-to-clean-the-database-and-sync-to-the-latest-state-again) -::: - - -### Run tower - -```bash -docker compose run tower -``` - - - - - - - - - - -## Create the docker-compose file (double IP) - -:::warning WIP Beyond this line - -::: - -__Dual NIC setup__ - -Part 1: Configure second IP - -Using Netplan (default ubuntu network manager), edit your `/etc/netplan/01-netcfg.yaml` - -Identify your ethernet id (enp5s0 in this example), add the second IP to its addresses list - -```bash -network: - version: 2 - renderer: networkd - ethernets: - enp5s0: - addresses: - - 188.primary.ip.here/32 - - 188.secondary.ip.here/32 # <--- add this line - - primary:ip:v:6/64 - routes: - - on-link: true - to: 0.0.0.0/0 - via: your.ip.subnet.mask - - to: default - via: fe80::1 - nameservers: - addresses: - - some.ip.v.4 - - some.ip.v.6 -``` - -Apply changes -`sudo netplan apply` - -Confirm changes -`ip addr` - -Under the modified interface, you should see the second IP address - -```bash -1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 - link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 - inet 127.0.0.1/8 scope host lo - valid_lft forever preferred_lft forever - inet6 ::1/128 scope host - valid_lft forever preferred_lft forever -2: enp5s0: mtu 1500 qdisc fq_codel state UP group default qlen 1000 - link/ether c8:7f:tag:tag:tag brd ff:ff:ff:ff:ff:ff - ############ - inet your.primary.ip.here/32 scope global enp5s0 - valid_lft forever preferred_lft forever - inet your.secondary.ip.here/32 scope global enp5s0 # <--- make sure second IP appears here - valid_lft forever preferred_lft forever - ############ - inet6 primary:ip:v:6/64 scope global - valid_lft forever preferred_lft forever -``` \ No newline at end of file diff --git a/docs_old/validators/yaml-templates/_category_.json b/docs_old/validators/yaml-templates/_category_.json deleted file mode 100644 index e7607a85..00000000 --- a/docs_old/validators/yaml-templates/_category_.json +++ /dev/null @@ -1,9 +0,0 @@ -{ - "label": "YAML Templates", - "position": 9, - - "link": { - "type": "generated-index", - "description": "Node YAML Templates" - } - } diff --git a/docs_old/validators/yaml-templates/fullnode-yaml.todo b/docs_old/validators/yaml-templates/fullnode-yaml.todo deleted file mode 100644 index 746b40c8..00000000 --- a/docs_old/validators/yaml-templates/fullnode-yaml.todo +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: "Fullnode yaml example" -id: "fullnode-yaml" ---- - -# NOTE: -You no longer have to modify a fullnode.yaml by hand, as there is now a tool to initialize fullnode configuration. - -That is: -`libra config fullnode-init` - -The following files should be maintained with the correct seed peers relative to the chain they serve: - -`mainnet`: -https://github.com/0LNetworkCommunity/seed-peers/blob/main/seed_peers.yaml - -`testnet` is TBD. - - -### ~/.libra/fullnode.yaml -``` -base: - role: 'full_node' - data_dir: '/home/vnuser/.libra/data' - waypoint: - from_file: '/home/vnuser/.libra/genesis/waypoint.txt' - -state_sync: - state_sync_driver: - # do a fast sync with DownloadLatestStates - # bootstrapping_mode: ExecuteOrApplyFromGenesis - bootstrapping_mode: DownloadLatestStates - continuous_syncing_mode: ExecuteTransactionsOrApplyOutputs - -execution: - genesis_file_location: '/home/vnuser/.libra/genesis/genesis.blob' - -full_node_networks: -- network_id: 'public' - listen_address: '/ip4/0.0.0.0/tcp/6182' - seed_addrs: - 1017ce1abc30e356660b8b0542275f2fb4373b5f8a82b7800a5b3fdf718ae55f: - - "/ip4/70.15.242.6/tcp/6182/noise-ik/0x1017ce1abc30e356660b8b0542275f2fb4373b5f8a82b7800a5b3fdf718ae55f/handshake/0" - dcab287b256bb1e90cda2537553ee19cac195ce67c2fefc7ff25b8aaf2368e6d: - - "/ip4/222.101.31.242/tcp/6182/noise-ik/0xdcab287b256bb1e90cda2537553ee19cac195ce67c2fefc7ff25b8aaf2368e6d/handshake/0" - 6ead5e1c7fe9f7c09e965f230cf8cf3cbbcacc33a562737aebd7387a90b04a43: - - "/ip4/65.109.80.179/tcp/6182/noise-ik/0x6ead5e1c7fe9f7c09e965f230cf8cf3cbbcacc33a562737aebd7387a90b04a43/handshake/0" - c04300abebc472cdea0e1f7160ece6c09e49145c2b5b72318bdc43c11aceb203: - - "/ip4/172.104.211.8/tcp/6182/noise-ik/0xc04300abebc472cdea0e1f7160ece6c09e49145c2b5b72318bdc43c11aceb203/handshake/0" - febaed185e04d0f158998b39501796d0b79235399796e96a1c9a3fac2f31ab57: - - "/ip4/38.242.137.192/tcp/6182/noise-ik/0xfebaed185e04d0f158998b39501796d0b79235399796e96a1c9a3fac2f31ab57/handshake/0" - 8ad0747d37cacdfb725a5de237fa2584342b9aabc28446064031166b371da938: - - "/ip4/160.202.129.29/tcp/6182/noise-ik/0x8ad0747d37cacdfb725a5de237fa2584342b9aabc28446064031166b371da938/handshake/0" - 9b07a7d587d5f515f4b77a2f751d0ca02e7a8cfb8f5550b26e5498d480cbd960: - - "/ip4/209.38.172.53/tcp/6182/noise-ik/0x9b07a7d587d5f515f4b77a2f751d0ca02e7a8cfb8f5550b26e5498d480cbd960/handshake/0" - -api: - enabled: true - address: '0.0.0.0:8080' -``` diff --git a/docs_old/validators/yaml-templates/validator-yaml.todo b/docs_old/validators/yaml-templates/validator-yaml.todo deleted file mode 100644 index 31c9b90a..00000000 --- a/docs_old/validators/yaml-templates/validator-yaml.todo +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: "Validator yaml example" -id: "validator-yaml" ---- - -# Validator YAML File Example - -### ~/.libra/validator.yaml - -``` -base: - role: 'validator' - data_dir: '/home/vnuser/.libra/data' - waypoint: - from_file: '/home/vnuser/.libra/genesis/waypoint.txt' - -consensus: - safety_rules: - service: - type: 'local' - backend: - type: 'on_disk_storage' - path: secure-data.json - namespace: ~ - initial_safety_rules_config: - from_file: - waypoint: - from_file: '/home/vnuser/.libra/genesis/waypoint.txt' - identity_blob_path: '/home/vnuser/.libra/validator-identity.yaml' - -execution: - genesis_file_location: '/home/vnuser/.libra/genesis/genesis.blob' - -validator_network: - discovery_method: 'onchain' - mutual_authentication: true - identity: - type: 'from_file' - path: '/home/vnuser/.libra/validator-identity.yaml' - -full_node_networks: -- network_id: - private: 'vfn' - listen_address: '/ip4/0.0.0.0/tcp/6181' - identity: - type: 'from_file' - path: '/home/vnuser/.libra/validator-identity.yaml' - -api: - enabled: true - address: '127.0.0.1:8080' -``` diff --git a/docs_old/validators/yaml-templates/vfn-yaml.todo b/docs_old/validators/yaml-templates/vfn-yaml.todo deleted file mode 100644 index e5f2e3a8..00000000 --- a/docs_old/validators/yaml-templates/vfn-yaml.todo +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "VFN yaml example" -id: "vfn-yaml" ---- - -# VFN Example YAML - -### ~/.libra/vfn.yaml - -``` -base: - role: 'full_node' - data_dir: '/home/vfnuser/.libra/data' - waypoint: - from_file: '/home/vfnuser/.libra/genesis/waypoint.txt' - -execution: - genesis_file_location: '/home/vfnuser/.libra/genesis/genesis.blob' - -full_node_networks: -- network_id: - private: 'vfn' - listen_address: '/ip4/0.0.0.0/tcp/6181' - discovery_method: 'onchain' - seeds: - 1234yourvalidatorpublickey: - addresses: - - '/ip4//tcp/6181/noise-ik/0x1234yourvalidatorpublickey/handshake/0' - role: 'Validator' -- network_id: 'public' - listen_address: '/ip4/0.0.0.0/tcp/6182' - discovery_method: 'onchain' - identity: - type: 'from_file' - path: '/home/vfnuser/.libra/validator-full-node-identity.yaml' - -api: - enabled: true - address: '0.0.0.0:8080' - -mempool: - default_failovers: 3 -```