GithubHelp home page GithubHelp logo

fioprotocol / fio Goto Github PK

View Code? Open in Web Editor NEW
52.0 26.0 15.0 90.64 MB

The FIO Protocol is a decentralized, open-source blockchain protocol that makes it easier and less risky to use blockchain tokens and coins.

Home Page: https://dev.fio.net/

License: MIT License

CMake 0.71% Shell 1.11% C++ 51.69% C 0.20% WebAssembly 43.24% Objective-C 0.01% Python 3.05%

fio's Introduction

FIO

The Foundation for Interwallet Operability (FIO) or, in short, the FIO Protocol, is an open-source project based on EOSIO 1.8+.

License

FIO License

Release Information

Releases

Build Information

The build and install scripts are located in ./scripts directory.

While there are several options, there are two primary build targets; the default build with no arguments, ./fio_build.sh, will build a dev-centric FIO chain, good for development and testing, and a release-centric build with the '-P' argument, ./fio_build.sh -P, which is a pinned build (to clang) for formal testing and release to the BP community. Execute ./fio_build.sh -h to output the complete usage.

Build

The build script first installs all dependencies and then builds FIO. The script has several options, including '-P' (pinned build), '-i' (install directory), and '-o' (build type, i.e. Release, Debug, etc.). Providing no options will use default options, i.e. a local build directory, $HOME/fio, as the install directory.

{% include alert.html type="danger" title="An operational FIO build requires clang 8" content="FIO chain requires clang v8 as part of the LLVM requirements. When executing the build, specify '-P' for a 'pinned' build to ensure the correct LLVM versions are used." %}

To build, first change to the ~/fioprotocol/fio folder, then execute the script as follows:

cd ~/fioprotocol/fio/scripts
./fio_build.sh -P

The build process writes temporary content to the build folder. After building, the program binaries can be found at build/programs.

Install

For ease of contract development, FIO will be installed in the ~/fio folder using the fio_install.sh script within the fio/scripts folder. Adequate permission is required to install in system folders, e.g., /usr/local/bin.

cd ~/fioprotocol/fio/scripts
./fio_install.sh

fio's People

Contributors

0xcasey avatar adsorptionenthalpy avatar arhag avatar asiniscalchi avatar b1bart avatar brianjohnson5972 avatar bytemaster avatar cj-oci avatar dskvr avatar edrotthoff avatar elmato avatar ericbutz avatar heifner avatar jgiszczak avatar kesar avatar kj4ezj avatar larryk85 avatar moskvanaft avatar nathanielhourt avatar norsegaud avatar paulcalabrese avatar pmesnier avatar scottarnette avatar sergmetelin avatar spoonincode avatar taokayan avatar tbfleming avatar thomasbcox avatar wanderingbort avatar zorba80 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

fio's Issues

[History] Certain actions missing from ABI

EOS Rio found that for the fio.treasury contract they could not trace certain actions. And the ones they listed are not in the fio.treasury contract abi. In some contracts we use inline actions of other contracts to change values in different tables , those actions have not been added to the abi of the contract that is calling it - therefore it might not be able to trace. Maybe any actions that happens in fio.common.hpp needs to be added to the abi of the contract that included the header and is calling the action in there

Allow top 42 BPs to set fee ratios and multiplier

Creating an issue to track discussions regarding enabling the top 42 BPs to be able to set fee ratios and multipliers so they can "signal" their fee intentions and so that when they move into top 21 their fees are ready to go.

ABI error in fio.address, "domains" table: wrong type for "expiration"

Current ABI returns uint32 for expiration field in "domains" table, but the contract defines it as uint64. This breaks decoding of domains in state history.

    },{
      "name": "domain",
      "base": "",
      "fields": [{
          "name": "id",
          "type": "uint64"
        },{
          "name": "name",
          "type": "string"
        },{
          "name": "domainhash",
          "type": "uint128"
        },{
          "name": "account",
          "type": "name"
        },{
          "name": "is_public",
          "type": "uint8"
        },{
          "name": "expiration",
          "type": "uint32"
        }
      ]
    },{

FIO v2.x required chain update

Important FIO Testnet update

FIO is in the process of testing a v2.0 upgrade to Testnet that will cause Testnet nodes that have not upgraded to fork off of the Testnet chain. It is thus important for all Testnet nodes (including signing, history, and API nodes) to upgrade to this version.

Previous Testnet version: v1.0.5 (https://github.com/fioprotocol/fio/releases/tag/v1.0.5)
New Testnet version: v2.0.0-rc1 (https://github.com/fioprotocol/fio/releases/tag/v2.0.0-rc1)

Schedule

All Testnet nodes must be updated according to the following schedule:

Step 1. Monday Jul-27: msig v1.0.5 (Completed)
Step 2. Thursday Jul-30: Testnet BPs upgraded to gemini chain code (Completed)
Step 3. Monday Aug-3: FIP-12 system contract msig approved (Completed)
Step 4. Wednesday Aug-5: Testnet forking transaction: addaction msigs approved for 50-60 fio actions
Step 5. Thu Aug 6 16:00:00 UTC 2020: The new actions table needs to be populated with all of the allowed actions in the fio protocol. If Step 4 is not fully executed by this date the blockchain will reject all actions that are not in the new whitelist table.

SPIKE: ABI Updates

Tracks the creation of a FIP or Spike focused on updating the ABI. There have been several requests from the community to update the ABI. We should collect all of the suggestions and ABI research.

v1.1.0 release tasks

  • Rebase Develop (Casey)

Testnet Release:

  • Create pre-release v1.1.0 (Casey)
  • Create Release Notes (Eric)
  • Update releases.md, label as "pre-release" (Casey)
  • Create msigs for Testnet (Casey/Bohdan)
  • Post msig and release info to FIO Testnet

Mainnet Release:

  • Update releases.md with final contract info (Casey)
  • Create msigs for Mainnet (Casey/Bohdan)
  • Post msig and release info to FIO Mainnet and FIO
  • Send API/History node upgrade notifications to all channels (Eric)

fio.fee contract optimizations

fio.fee contract as of 60e0f50 in master branch:

Line 175, 293: actor should be of type "name", to let the serialization API check the validity and save on conversion time.

Lines 194, 203: index object initialization involves looking up in nodeos tree of indexes, and it does not need to be within the loop. These objects can be initialized only once.

Line 209: the while() loop goes through every endpoint in the votes table for this voter, and every iteration requires a deserialization of a vote object. This loop can be done cheaper if there's a 64bit hash index for (voter, endpoint) tuple. In this case, there would be one lookup most of the time, and more lookups in extremely rare occasions when the hashes collide.

Lines 234-239 are obsolete because it's cheaper to modify an existing row instead of deleting it and emplacing a new one.

Line 39: map<string, double> producer_fee_multipliers_map; should be defined as <uint64_t, double> in order to save on repetitive conversion fromnametostring`.

update_fees() should be reorganized in the following way: whenever a new vote is cast, the smart contract needs to keep a table of endpoints that need an update. Then update_fees() has a limit of calculations as an argument, and stops processing after reaching this limit. So it gets the first endpoint from the list of those needing an update, calculates the median, and keeps track of the number of executed calculations (basically, the number of voters). It stores the update and deletes the endpoint name from the update queue, and checks if the limit of calculations is reached. If so, it finishes the action. Subsequent calls to update_fees() will continue processing what is left.

If no fees require an update, the action may succeed or reject, depending on requirements. If it's triggered by an external oracle, it's beneficial to reject and save on blockchain resource.

Floating point fees can be replaced with an integer and 1000x multiplier. That will reduce the costs of calculations.

Lines 157-161: it only makes sense to initialize those indexes in constructor which are utilized in every action. The constructor is called at the start of every action, and index initialization takes time (nodeos looks up in the global table of smart contracts). Normally the action code would only initialize those tables which are in use in this action.

Line 279: the updatefees action does not require any authorization, and it's probably better to let anyone trigger the recalculations. Then BP can do it without a multisig.

Define maximum string length in fio.address

fio.address accepts any string length for name and domain strings, and it causes a difficulty in integrating FIO with other systems. There should be a reasonable maximum length of name and domain, maybe 256 symbols.

[FIP-4] Provide ability to remove pub addresses

fioprotocol/fiosdk_typescript#19 [TypeScript SDK] Add removePublicAddress to SDK
fioprotocol/fiosdk_typescript#20 [TypeScript SDK] Add removeAllAddresses to SDK
fioprotocol/fiosdk_ios#4 [iOS SDK] Add the new removePublicAddress call to the iOS SDK
fioprotocol/fiosdk_ios#5 [iOS SDK] Add removeAllAddresses to SDK
fioprotocol/fiosdk_kotlin#5 [Kotlin SDK] Add removeAllAddresses to SDK
fioprotocol/fiosdk_kotlin#6 [Kotlin SDK] Add removePublicAddresses to SDK
#108 FIP-4: QA Tests for removePublicAddress

Whitelisting contract actions

Prior to mainnet, development addressed several vulnerabilities that arose as a consequence of FIO's fee-based protocol. One of these was the ability to send transactions to non-existent actions and having the transaction record be recorded in the blocklog. Because no fee would be charged for a non-existent action, it opened an attack vector which would enable the bloating of the FIO log file with large non-existent action calls.

To address this issue, a "whitelist" of actions was created that would be checked, and thus transactions sent to non-existent actions would be rejected prior to being recorded in the blocklog. This check was added to apply_context.cpp:

c001822

While it was understood that this would require an update to chain code every time a new action was added to FIO, the larger repercussions of this creating a hard fork in FIO every time a new action was added was not fully conceptualized. Obviously, this is not a feasible path.

This issue opens the discussion regarding possible solutions.

Make a Fee Multiplier voting tool.

Background:

Determination of fees in the FIO protocol is inherently complex.
Determination of block producer fee votes, and the selection of fees used within the FIO protocol is a complex process that is multi faceted and layered. It is multi faceted because it involves complex analysis of market factors, token price, protocol governance considerations, cost of BP resources, and resource consumption to determine the fee vote of a given block producer. It is layered because once fee votes are placed by block producers, the vote of each BP is derived from the fee multiplier, and fee ratios which they input during the voting process. It is further layered because following the computation of the BP vote, a final fee determination is then made by the FIO protocol based on the median of the votes present as long as there are over 15 votes from the active BPs for a given fee. Additionally, It is in the protocols best interest to provide a tenable set of fees to the FIO protocol user community. Block producers are faced with the barrier of understanding these many facets and layers as they participate in the fee voting process of the FIO protocol.

Motivation:

The fee multiplier must be updated by block producers as the value of the FIO token changes or we risk the value of the token influencing the fees to make them un-tenable for FIO users. If fee multipliers are too quickly or too slowly modified in response to token fluctuations the result can also become un-tenable fees for FIO users. We consider to provide tooling that will facilitate the setting of the multiplier fee vote for block producers. This can be used immediately by BPs once the FIO token is listed on its' first exchanges.

Security Considerations:

Any tool we create needs to be resistant to tampering and hacking and bad data from exchanges. We want to encourage diversity in the block producer community regarding both the process and data sources used during the selection of fee votes.

Scope of project:

Deliver a reference implementation, guidelines, and alternate implementations for use by block producers.

Important Considerations:

Deliver a reference implementation that can be used immediately as the FIO token value fluctuates after its' initial listing.
Provide a reference implementation that meets the BP community needs.
– Technology choice should be BP selected.
– Involve the BP community as early as this document is agreed.
Provide guidance to BPs regarding how often to perform the voting for the multiplier.
Provide alternate implementations that may be considered for use by the BPs

Deliverables:

A description of the motivations for this effort.
A working tool/reference implementation that enables a BP to set the fee multiplier based on the present exchange rates of the FIO token.
Guidelines for BPs to help in their fee voting participation.
References to other tools that can be used by block producers to establish the value of their fee vote.
 
Functional Considerations of reference implementation:

The tool will be implemented in javascript (npm).
The tool will permit a user to configure the FIO private and public keys to be used in updating the fee multiplier.
The tool will provide a set of pluggable data providers, each providing token pricing.
The tool will highlight any prices that are outliers in the token pricing.
The tool will provide the ability to select multiple data sources for use in price determination.
The tool will determine price using the median of the selected data sources.
The tool will update the fee multiplier on the FIO protocol for the specified public key by deriving the actor when the update blockchain setting is enabled.
The tool will provide a setting to enable/disable the update of the multiplier vote on the FIO chain.
The tool will provide a setting to enable/disable the output of information relating to pricing and the multiplier used. (this will be in json format)

Guidelines for use:
 
Price Increases for FIO Token:

When the FIO Token goes up in value, the consequences to the chain are that users may choose to abandon interacting with the chain because its too expensive, this can have the effect of reducing (or eliminating) community interest in the FIO protocol.

Price decreases for FIO Token:

When the price decreases for the FIO Token, the consequences are that users may choose to exploit these changes and perform many operations on the FIO protocol at a reduced cost.
 
It is recommended that block producers run this tool periodically and check if the variance of the FIO Token value deviates by some threshold. For Example : run this tool once every hour. take immediate action whenever a price change occurs that exceeds 5% of the token value. Each BP should come up with the periodicity, and threshold they are comfortable with.
 
 
Notes on exchange APIs

https://api.binance.com/api/v3/avgPrice?symbol=BTCUSDT

{
    "mins": 5,
    "price": "9785.67139226"
}
 
https://aws.okex.com/api/spot/v3/instruments/BTC-USDT/ticker

{
    "best_ask": "9775.6",
    "best_bid": "9775.5",
    "instrument_id": "BTC-USDT",
    "product_id": "BTC-USDT",
    "last": "9777.6",
    "last_qty": "0.005091",
    "ask": "9775.6",
    "best_ask_size": "4.04186337",
    "bid": "9775.5",
    "best_bid_size": "7.68796495",
    "open_24h": "9631",
    "high_24h": "9840.1",
    "low_24h": "9591.4",
    "base_volume_24h": "72333.14938632",
    "timestamp": "2020-05-20T13:45:02.704Z",
    "quote_volume_24h": "704151900.9"
}
 
https://api.huobi.pro/market/detail/merged?symbol=btcusdt
{
    "status": "ok",
    "ch": "market.btcusdt.detail.merged",
    "ts": 1589982375689,
    "tick": {
        "amount": 30354.12683700983,
        "open": 9617.02,
        "close": 9781.73,
        "high": 9840.0,
        "id": 215095134870,
        "count": 394450,
        "low": 9591.83,
        "version": 215095134870,
        "ask": [
            9781.73,
            0.044205
        ],
        "vol": 2.9560206460750693E8,
        "bid": [
            9780.23,
            0.20223
        ]
    }
}
 
Considered References:

Someguy123/steemfeed-js.

We recommend using this as a starting point for our tool, it is pluggable, it will still need extensive modification to make into what we want to provide
this is a javascript implementation,
it uses an adapter model to permit plugin access to various exchanges, it already support Binance, and Huobi and others.
it interfaces to steem accounts, and does not perform any kind of median, or other checks to filter out abhorrent data.

coingecko/steemprice-feed

this is typescript, interfaces to coin gecko for pricing, does not perform any kind of median or other checks to filter out abhorrent data.

Netherdrake/conductor

this is a python implementation that is implemented to manage steem witnesses, heavily integrated with steem.
 

FIP-4: QA Tests for removePublicAddress

Developers need to take on more of the initial QA so Pawel can focus on requirements and design. As part of that I would like the developers to take a cut at using the FIO TypeScript SDK test harness as a possible solution for QA testing. It allows for calls into the ABI and into clio directly so is fairly flexible.

As a first step let's implement some tests for FIP-4. We can get some use cases from Pawel and see how difficult it is to implement those in JS.

The JS test harness can be installed and run from:

https://github.com/dapixio/fio.test

The current utils and code is in rough form and we will need to evolve it to make it more efficient if we decide to use it

Unlinkauth missing from action mapping

Bohdan Kossak(opens in new tab) 4:54 AM
Hi, one thing found today when was updating permissions for our account and try to remove no needed one (using clio)..

Ability to set additional proxy info like name and voting philosophy

It would be great to have an API call for proxies to set optional additional information about themselves such as name, website, and voting philosophy. This is typically implemented on EOSIO chains on the regproxyinfo account with this contract:

https://github.com/AlohaEOS/eos-proxyinfo

Perhaps for FIO it's a new API endpoint such as /register_proxy_info and it could use the same proxies table but on the eosio account. Using the same table structure will make it easier for existing EOSIO tools and wallets to integrate.

Why does voteproducer require a FIO Address?

Other calls use the signing actor, a specified actor, or FIO public key. Is there a reason this call is different? It creates a workflow problem where someone may have a FIO account with tokens and they want to participate in governance and vote with those tokens, but they don't intend to use that account for FIO protocol activities.

V1 history-plugin data folders - need default location, conditional creation

Two issues:

  • The history and history_index folders are created even if the v1 history plugin is not enabled. It would be preferable that these are only created when the plugin is enabled.
  • These do not default to the data-dir if no setting is present in the config.ini or on the command line, resulting in the directories being created in the user's home directory. If no directory is specified, these should default to the data-dir alongside other chain data.

Hints:
https://github.com/fioprotocol/fio/blob/develop/plugins/chain_plugin/chain_plugin.cpp#L711
https://github.com/fioprotocol/fio/blob/develop/plugins/chain_plugin/chain_plugin.cpp#L729
https://github.com/fioprotocol/fio/blob/develop/libraries/chain/controller.cpp#L301

FIO Fee Update

Tracks discussion surrounding FIO BP update of FIO Fees.

The following price data is taken from Coingecko FIO Protocol USD (Historical Data)
https://www.coingecko.com/en/coins/fio-protocol/historical_data/usd#panel

snapped_at | price
2020-07-13 00:00:00 UTC | 0.113946112
2020-07-14 00:00:00 UTC | 0.113946112
2020-07-15 00:00:00 UTC | 0.086577099
2020-07-16 00:00:00 UTC | 0.093932881
2020-07-17 00:00:00 UTC | 0.084144208
2020-07-18 00:00:00 UTC | 0.083985383
2020-07-19 00:00:00 UTC | 0.083476238
2020-07-20 00:00:00 UTC | 0.124258708
2020-07-21 00:00:00 UTC | 0.148377484
2020-07-22 00:00:00 UTC | 0.181089225
2020-07-23 00:00:00 UTC | 0.181444731

11 day average price: 0.118
7 day average price: 0.127
5 day average price: 0.144

Current FIO Fee for register_fio_address: 40 FIO

Current price of register_fio_address in USD using 11 day average: 40 FIO * 0.118 = $4.71
Current price of register_fio_address in USD using 7 day average: 40 FIO * 0.127 = $5.07
Current price of register_fio_address in USD using 5 day average: 40 FIO * 0.144 = $5.75

Target price of FIO Address is $2.00

Suggested FIO Fee for register_fio_address using 11 day average: $2.00 / $4.71 * 40 ~ 17 FIO (multiply current fee by .42)
Suggested FIO Fee for register_fio_address using 7 day average: $2.00 / $5.07 * 40 ~ 16 FIO (multiply current fee by .39)
Suggested FIO Fee for register_fio_address using 5 day average: $2.00 / $5.75 * 40 ~ 14 FIO (multiply current fee by .34)

Proposed: Multiply current fees times 0.35
(Current fees: https://www.alohaeos.com/tools/fiofees)

The new register_fio_address fee would be 14
If FIO trades at ~$0.14 a FIO Address would cost $0.14 * 14 = $1.96

The best way to think of this is to agree on what the assumed exchange rate might settle at in the near future. This proposal suggests $0.14

Determination of date and time of forking deadline for Test net rollout of gemini

This issue tracks the determination of the forking deadline for test net rollout of gemini.

The forking deadline must be set for the test net and main net releases (main net will be addressed separately).

The forking deadline should be the block time that the FIO protocol will begin using the new action mapping that is in state. After this time any nodes that have not upgraded to the gemini release for testnet will fail to work properly.

the forking deadline should include adequate time (and some cushion) for the following activities

  1. coordinate all BPs and perform the upgrade of the chain code to the gemini binaries.
  2. verify the upgrade of all who are required to upgrade.
  3. perform the MSIG for the set code of the gemini system contract modification (must happen after step 2)
  4. perform the MSIG to add the 50-60 actions (by calling the new system contract action called addiction).

The present idea is to set the forking deadline for test net to be Monday August 10 2020 at 12pm UTC
(6am MST).

please add your comments and suggestions and we will try to finalize the time In the next 24 hours (deadline for decision is July 23 7pm UTC)...

Thank you for your participation.

Enhance clio

Includes enhancements to clio:

  • Update clio to reflect the custom calls for FIO

  • Confusing error messages in clio

Determine best practices of table migration, establish a new table, retire an old table

Purpose:

The purpose of this issue is to stimulate and capture discussion surrounding best practices of table migration for the scenario when one or more tables in the present design are being refactored into one new table, and migration is required. There are 5 phases/steps proposed. All feedback on this process is welcome, and the goal is to arrive at a detailed understanding of the aspects of migrating the data for this particular scenario.

Phase 1:

Establish the new table using indexes from the old (no auto indexing)

The new table will be established to use primary Ids that are from the old table.
Contract mods will be put into place that emplace into both the new table, and the old table.

The old table will maintain auto indexing of primary key.
The contract using the new table will emplace the primary key using the old tables pkid and will not use auto indexing.

Contract actions will be modified to perform the emplacements into the old and the new table.

Phase 1 Results:

We have an old table fully populated, and a new table with records that are from the time since the set code which establishes the new table (ids not in the new table need migrated from the old table).

Phase 2 –

Migrate the old table to the new for all entries not in the new table.

Run a migration action that performs this migration for all ids not in the new table.

Phase 2 result:

We have the old table and the new table fully in sync. The old table is still being used by the actions and end points of the chain.

Phase 3:

establish the final concept.

Establish the final contract versions (using auto indexing of pkid on the new table) along with all contract mods supporting the use of the new table in the desired final form.

Phase 3 Result:

now we have the new table in place, and the old table is retired. all desired contract changes are in place. the fix is in!! The old table remains JIC.

Phase 4:

Let it set in. (regression and load testing, test net only)

Phase 5:

removal of the old table.

Why do the fio.token and fio.address accounts have a proxy set?

I've discovered this on FIO Mainnet:

clio get table eosio eosio voters -l 1 -L 37
{
  "rows": [{
      "id": 37,
      "fioaddress": "",
      "addresshash": "0x00000000000000000000000000000000",
      "owner": "fio.token",
      "proxy": "qcic4ydb3vqh",
      "producers": [],
      "last_vote_weight": "0.00000000000000000",
      "proxied_vote_weight": "0.00000000000000000",
      "is_proxy": 0,
      "is_auto_proxy": 1,
      "reserved2": 0,
      "reserved3": "0 "
    }
  ],
  "more": true
}

Which is odd, as qcic4ydb3vqh seems to be a normal user account. That is_auto_proxy value leads me to believe setautoproxy may have been called on these accounts. Is this a bug?

State optimization and state management

This story does not require development. It tracks the need to review what FIO stores in state and to decide what data should 1) always be in state, 2) be in state until expiration, 3) never be in state.

Research should be collected in the wiki page (or in a GitHub issue).

https://stealth.atlassian.net/wiki/spaces/DEV/pages/290226286/State+optimization+and+state+management

UAT:

  • Review findings with team.
  • We can then decide on what we want to take on in the near future.

v1.0.3 release tasks

Testnet Release:

  • Create pre-release v1.0.3 (Casey)
  • Create Release Notes (Eric)
  • Create PR for releases.md. Do not merge until Mainnet release. (Casey)
  • Create msigs for Testnet (Casey/Bohdan)
  • Post msig and release info to FIO Testnet

Mainnet Release:

  • Merge PR into releases.md with final contract info (Casey)
  • Create msigs for Mainnet (Casey/Bohdan)
  • Post msig and release info to FIO Mainnet and FIO
  • Send notifications to all channels (Eric)

Create /get_actor endpoint

Create /get_actor endpoint which would take "fio_public_key" and return actor. This is just hashing, no table lookups.

Need on-chain abi for new funds request and record obt "content" field

We should seriously consider publishing the abi that defines the content field for OBT requests along with the contract. If this is not done, it will not be possible to change the definition of the (encrypted) fields without breaking clients.

For example, when we updated the spec to include a chain code and token code, all of the clients required manual updates.

If we make a change in the future, how will clients know when to use what version? Because of this, the ABI for this field should be included when publishing the contract, allowing older ABIs to be pulled from a history node and allowing for future compatibility.

require_auth on createfee should be set to topprods

This change will allow any of the top 21 Block Producers the ability to create new endpoint fees associated with contract actions. This will help mitigate possible future msig proposals and allow ease of use for future development.

createfee currently requires 3 expressions. This purposed change will require the actor parameter to be passed to allow for proper validation:

  • end_point
  • type
  • suf_amount
  • actor

updateauth not recorded by v1 history plugin if account does not exist when referenced

It appears one of the history tables isn't getting updated when an account does not exist but is referenced in an updateauth call:

Example, two accounts both having been delegated a linked permission: one shows no trace in either the block explorer or the get_controlled_accounts endpoint and other does:

curl -s -XPOST http://testnet.fio.dev/v1/history/get_controlled_accounts -d '{
  "controlling_account": "gjkdwmtx2tse"
}'
...
{
  "controlled_accounts": [
    "l35p5swqgvoo"
  ]
}

vs.

curl -s -XPOST http://testnet.fio.dev/v1/history/get_controlled_accounts -d '{
  "controlling_account": "voterxbrq3vw"
}'
...
{
  "controlled_accounts": []
}

The difference is that the first account was created via newaccount after a trnsfiopubky. The second account was linked before the account had been created.

It may be a good idea to either 1) reject updateauth referencing a public key without an entry in the accountmap table for fio.address, or 2) modify the v1 history plugin to index the event. I'm guessing option 1 is much less work.

Neither account show traces of the activity when calling get_actions, though I'm not certain this behavior differs from eos' v1 history plugin and I suspect that's ok - indexing that would require inspecting the action details since the account is neither the receiver or actor.

In get_obt_data fio_request_id is set to 0 when it was empty, but 0 is an actual fio_request

In get_obt_data fio_request_id is set to 0 when it was empty, but 0 is an actual fio_request.

Pawel 12:20 PM
I'm not sure I understand. When I call get_obt_data I get a record which says fio_request_id = 0. It could either be referencing FIO Request with id of 0, or it could be saying there is no corresponding fio request. How am I supposed to know which one is which?

Ed 12:25 PM
that return should be a signed int instead of uint64_t and should be negative or something when no id.. its a bug

Votes table should store FIO Address

When voting FIO Address is used, but account name is recorded in votes table. It's therefore not easy to recall what FIO Addresses the user voted on.

Votes table should store FIO address and get_account should return FIO Addresses in voter_info

Add support for the PUB_K1 public key format to v1/chain/get_fio_names

It'd be very helpful of the FIO specific API endpoints that deal with public keys also support the PUB_K1 format of keys, which is what eosjs v20+ deals with internally for the most part. The endpoint I ran into where this was unsupported was the /v1/chain/get_fio_names endpoint, though there may be others that accept public keys as inputs that this would also help support.

For example, this does not currently work:

curl https://fiotestnet.greymass.com/v1/chain/get_fio_names -d '{"fio_public_key":"PUB_K1_6smr7ThQMWYBHzEvkzTZdxNNmUwxqh2VXdXZdDdzYHgak1U8Di"}'

I discovered the v1 history plugin endpoints already support both, likely because the conversion is happening. Examples as follows.

Using a PUB_K1 public key:

curl https://fiotestnet.greymass.com/v1/history/get_key_accounts -d '{"public_key":"PUB_K1_6smr7ThQMWYBHzEvkzTZdxNNmUwxqh2VXdXZdDdzYHgak1U8Di"}'

Using a FIO public key:

curl https://fiotestnet.greymass.com/v1/history/get_key_accounts -d '{"public_key":"FIO6smr7ThQMWYBHzEvkzTZdxNNmUwxqh2VXdXZdDdzYHgakgqCeb"}'

Correctly update last_voting_weight and

Fixes to voting weights, including:
MAS-1539: Registering/unregistering as a proxy does not correctly update last_voting_weight
MAS-1489: Voting: When a user proxies their vote, the total_voted_fio increases by 2x their vote strength

v2.x Testnet reset plan

This issue explores our options for upgrading Testnet to our “2.x” version. For this release we will be separating out our contract code into a separate repo fio.contracts and thus versioning of chain code and contract code will start to diverge.

Mainnet is currently at:

  • Chain code: v1.0.5
  • Contract code: v1.0.5

Testnet is currently at:

  • Chain code: v1.1.0
  • Contract code: v1.1.0

Our goal is to get Mainnet to:

  • Chain code: v2.x. This includes:
    • The previous v1.1.0 code that was deployed to Testnet
    • FIP-12 fix to prevent future forks when new actions are deployed.
    • Because this is a forking change we will include a block number or date in the code after which any nodes on the old version will be forked.
  • Contract code: v1.0.6
    • Released on top of v1.0.5
    • Only includes the fix for FIP-12 which prevents future forking when adding new actions

The question is how to best upgrade and test on Testnet since we have already deployed the v1.1.0 contracts. I see a few options:

A. Work from current Testnet setup:

  1. Downgrade contracts to v1.0.5
  2. Update chain code to v2.x (forking change with dates set for upgrade deadline)
  3. Update contracts to v1.0.6

Main issues with this approach:

  • Need to test how the change from v1.1.0 to v2.x and the upgrading/downgrading of contracts would affect replay.
  • It is not a “clean” test of what will happen on Mainnet.

B. Set up a separate "Devnet" that mimics the current Mainnet setup and use that for the primary testing.

  1. Create a baseline v1.0.5 network
  2. Upgrade Devnet nodes to v2.x chain code. Enable Testnet BPs to join the Devnet network for testing.
  3. Update contracts to v1.0.6

Main issues with this approach:

  • The testing is occurring outside of Testnet.

C. “Reset” testnet from genesis to v1.0.5

Main issues with this approach:

  • We are not sure about all of the repercussions.
  • Is it possible to resync to mainnet? How troublesome is a reset to genesis?

Please give feedback regarding which approach (or combination of approaches) makes the most sense and can be accomplished in the shortest timeframe.

TPID was not processed when provided in addaddress

KB references a tpid but it is not processed when used in addaddress action of fio.address contract
https://developers.fioprotocol.io/api/api-spec/reference/add-pub-address/add-pub-address-model

~/fio/1.0/bin/clio -u http://localhost:8889 push action -j fio.address addaddress '{"actor":"j2x22kkddut1","fio_address":"adam@dapix","public_addresses":[{"chain_code":"BTC","token_code":"BTC","public_address":"1ERJT3s8BsYLh6M2251KF1ZPvuAADV1KEn"}],"max_fee":40000000000,"tpid":"adam@dapix"}' -p j2x22kkddut1@active

adam$ ~/fio/1.0/bin/clio -u http://localhost:8889 get table fio.tpid fio.tpid tpids

{ "rows": [], "more": false }

MAS-1624 - Testnet: bpclaim voting threshold error

fio.common.hpp was included with the latest msig proposal and it pulled in the 65M vote threshold. There are several checks in the code that prevent certain actions if votes fall below that threshold. We need to decide if we want to:

  • Keep the 10M threshold in Testnet which could be hard to maintain going forward.
  • Get the votes up to 65M

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.