• Who can freeze a token? Just its creator?
• Do we need freezing specific accounts with the token?

For DEX(decentralized exchange) support with the offer rate method like Stellar,
https://www.stellar.org/developers/guides/concepts/exchange.html
https://www.stellar.org/developers/guides/concepts/list-of-operations.html#manage-offer
Yosemite requires the minimum precision of 2 or 4.

Directory Description

• unittests : tests for smart contracts
• tests : tests for chain node (including plugins)
• scripts : test scripts for tests
• programs/eosio-launcher : node executer for tests

Executing unit test

• How to execute only one test case of unittests
  cd build/unittests
  ./unit_test -t auth_tests/linkauth_special --report_level=detailed --color_output -- --binaryen
• How to execute all test cases of unittests (except weighted_cpu_limit_tests)
  ./unit_test -t !wasm_tests/weighted_cpu_limit_tests --report_level=detailed --color_output -- --binaryen

The EOS.IO software determines its native token symbol at compile time, which its default is SYS,4.
contracts/eosiolib/core_symbol.hpp.in

We must make a decision whether to use compile time approach or runtime approach. For compile time approach, we have to make binaries and release them for each FIAT token(e.g. DKRW, DUSD). For runtime approach, there are two ways to determine the native token symbol, genesis block approach or smart contract(yx.system or yx.ntoken) approach.

when system depository issues new native tokens, "issuen" action instead of 'transfer' action is notified to user accounts.
need to check if there is a way to notify only 'trasfer' actions on user accounts

$YOSEMITE_CLEOS push action yx.ntoken issuen '["producer.a",{"quantity":"100000.0000 DKRW","issuer":"sysdepo"},"issuen test"]' -p sysdepo@active
executed transaction: a60a8741da2360948e6450bd58408e7f00c433d9b3d5c519d0a6f2987ec7b710  136 bytes  2099 us
#     yx.ntoken <= yx.ntoken::issuen            {"to":"producer.a","quantity":{"quantity":"100000.0000 DKRW","issuer":"sysdepo"},"memo":"issuen test...
#       sysdepo <= yx.ntoken::issuen            {"to":"producer.a","quantity":{"quantity":"100000.0000 DKRW","issuer":"sysdepo"},"memo":"issuen test...
#    producer.a <= yx.ntoken::issuen            {"to":"producer.a","quantity":{"quantity":"100000.0000 DKRW","issuer":"sysdepo"},"memo":"issuen test...

currently only total supply of all native token is traced in contracts.
total supply of native tokens issued by each system depository needs to be traced also in contract

separate payer-specified transfer and implicit self-payer transfer to reduce net bandwidth and action log

• YOSEMITE Chain System Account : eosio => yosemite, eosio.msig => yx.msig, eosio.prods => yx.prods
• binary executable names : yosemite (blockchain node), clyos (chain client command line interface), keyos (key daemon)

As our roadmap,
https://docs.google.com/spreadsheets/d/1StkJAtmHXjCj18N32YS2sYWBMZy_tHnp7NnSWhKL0T0/edit#gid=0,
says that target for the smart contract platform is 2019 July. But the EOS.IO software is already the smart contract platform based on its EOS token model, which is not fit to our fee-based system.

We must commenting out the all the checking logics of resource limitation for CPU, NET, and RAM DB not to check limit per account. We're going to modify the logics for our system.

#ifdef YX_SMART_CONTRACT_PLATFORM
#endif

Let's remove commands which is not aligned with our chain.

Let's implement escrow service for native token and non-native tokens.
https://blog.localethereum.com/how-our-escrow-smart-contract-works/

shell script to reset Testnode in test server or local machine

It would be easier to read if we represent KYC vector values with left-shift operator such as 1 << 0

Transaction-as-a-vote message protocol should be implemented before first public launching of YOSEMITE blockchain(permissioned version)

libraries/chain/eosio_contract.cpp

naming needs to be changed to 'initialize'
This transaction is one time 'initialization' transaction which should be called by system account (not by a depository) in BIOS process

currently KYC_VECTOR_REAL_NAME_AUTH and KYC_VECTOR_BANK_ACCOUNT_AUTH is hard-coded KYC policy for the native token operations, needs to think about configurable impl.

• chain_plugin::get_account()
• clyos get_account callback

nodeos -> yosemite
cleos -> clyos
keosd -> keyos

Note that yos is from 'Yos'emite.

• transaction vote collection - by "cast_transaction_vote" API
• block producer election - by "read_head_block_trx_votes_data" API running on 'onblock' action of system contract

Let's make optional appbase-plugin to notify dapps their registered events using WebSocket. The foremost feature is notification of transaction irreversibility.

eosio and eosio. can be changed by cmake build time.

• consider yx.ntoken and yx.token
  For native token balance, /v1/chain/get_native_token_balance and get_native_token_stats will be added.
  For non-native token balance, /v1/chain/get_token_balance and get_token_stats will be added.
• /v1/chain/get_currency_balance and /v1/chain/get_currency_stats are not compatible for Yosemite. They are not supported.

eosio_install.sh and eosio_uninstall.sh shall be named to yosemite_ and their content must be adjusted

In current implementation, the authorized Depositories also have the right for verifying user's identity(KYC) and publishing KYC info (only whether an account has gone through KYC process provided by a trusted entity) on blockchain. The separate authority account management should be implemented on system contract for registering identity authorities whose right should be authorized by the active block producers.
The authorized Identity Authorities have the right for managing user info and KYC info on blockchain.

Implement ebay-like open auction service on blockchain for Non-Fungible Tokens (#107)

remove ntaccounts row when token balance is zero to reduce storage consumption

YOSEMITE Proof-of-Transaction(PoT) and Transaction-as-a-Vote (TaaV)

Proof-of-Transaction (PoT) incentivizes the application service providers directly contributing to the blockchain ecosystem by generating actual blockchain transactions, quantitatively measured by Transaction-as-a-Vote (TaaV).

The key idea that makes Proof-of-Transaction a novel blockchain consensus mechanism is the concept of Transaction-as-a-Vote (TaaV). Transactions generated by the client side of the blockchain applications can optionally include a vote for a block producer candidate who can potentially participate or is already participating in the blockchain consensus process. In blockchain transaction messages which would incur some transaction fee, there is an optional "transaction vote" field where a blockchain account address can be specified as a vote. That means the entity generating the transaction on blockchain wants the blockchain core node having the voted address to be a block producer.

• Currently each system contract manages its own transaction fee setup. (yosemite::fee_contract)
• transaction fee amount for each system operation should be managed in one contract (system_contract), tx fee can only be updated by 2/3+1 agreement of active block producers
• design more flexible fee system (supporting different fee policy for different account type, need to be incorporated to the account type/state design)

[ntoken::issuen]
there is no checking if a transaction in context has authority for system depository

Options:
-v,--trx-vote TEXT transaction vote target account, Transaction-as-a-Vote(TaaV) for YOSEMITE Proof-of-Transaction(PoT)

For each blockchain account, Identity Authority can manage below information

• account type (e.g. normal, system, ...)
• KYC info. (e.g. email, phone, real name, bank account, ...)
• account state (e.g. blacklisted account, ...)
• Identity-Authority specific data (arbitrary string data)

once an Identity Authority sets identity info. for an account, only the Identity Authority account can modified the identity info for the account.

EOS/fc modifies that every HTTP response has Connection:close header, which we cannot accept.

https://github.com/YosemiteLabs/fc

for tx fee transfer, separate token transfer action (specifying tx fee amount) should be notified to the fee account.

$YOSEMITE_CLEOS push action yx.ntoken transfern '[ "producer.a", "producer.b", {"quantity":"10000.0000 DKRW","issuer":"sysdepo"}, "producer.a", "memo" ]' -p producer.a
executed transaction: 8fe5f4647657a9576b6fae3e37eda9899e12a9d5fbd4902cac68c8c7673b7efc  152 bytes  1667 us
#     yx.ntoken <= yx.ntoken::transfern         {"from":"producer.a","to":"producer.b","quantity":{"quantity":"10000.0000 DKRW","issuer":"sysdepo"},...
#    producer.a <= yx.ntoken::transfern         {"from":"producer.a","to":"producer.b","quantity":{"quantity":"10000.0000 DKRW","issuer":"sysdepo"},...
#         eosio <= yx.ntoken::transfern         {"from":"producer.a","to":"producer.b","quantity":{"quantity":"10000.0000 DKRW","issuer":"sysdepo"},...    =======> invalid action notification
#    producer.b <= yx.ntoken::transfern         {"from":"producer.a","to":"producer.b","quantity":{"quantity":"10000.0000 DKRW","issuer":"sysdepo"},...

For example, user1 has native tokens like 10000.0000@d1, 100@d2 and the tx fee of ntransfer is 100.
When user1 tries to do 'ntransfer' 10000@d1 to user2, the fee can be charged with 100@d1, so the ntransfer can fail.

libraries/chain/include/eosio/chain/config.hpp

const static uint64_t system_account_name    = N(eosio);
const static uint64_t null_account_name      = N(eosio.null);
const static uint64_t producers_account_name = N(eosio.prods);

const static uint64_t eosio_auth_scope       = N(eosio.auth);
const static uint64_t eosio_all_scope        = N(eosio.all);

const static uint64_t eosio_any_name = N(eosio.any);
const static uint64_t eosio_code_name = N(eosio.code);

...