摘要:第一種創(chuàng)建系統(tǒng)賬號的方式。的默認合約是來自源碼提前定義好的。具體的信息在,。判斷的合法性只有才能創(chuàng)建為前綴的賬號。第三種當部署合約時,創(chuàng)建賬號都必須使用該合約的的。值得一提的是用第三種方式創(chuàng)建時,第二種方式的也會執(zhí)行。
第一種:創(chuàng)建系統(tǒng)賬號eosio的方式。
直接調用create_native_account 方法直接進行創(chuàng)建。并將資源設置成無限。
void create_native_account( account_name name, const authority& owner, const authority& active, bool is_privileged = false ) { //create account 直接創(chuàng)建賬號,不會做任何資源判斷,因為創(chuàng)建的是系統(tǒng)賬號 db.create([&](auto& a) { a.name = name; a.creation_date = conf.genesis.initial_timestamp; a.privileged = is_privileged; if( name == config::system_account_name ) { a.set_abi(eosio_contract_abi(abi_def())); } }); db.create ([&](auto & a) { a.name = name; }); const auto& owner_permission = authorization.create_permission(name, config::owner_name, 0, owner, conf.genesis.initial_timestamp ); const auto& active_permission = authorization.create_permission(name, config::active_name, owner_permission.id, active, conf.genesis.initial_timestamp ); //初始化賬號資源,但是初始化賦值只賦了resource_limits_object的owner值,其他cpu,ram,net等資源默認是-1,也就是unlimit。 resource_limits.initialize_account(name); int64_t ram_delta = config::overhead_per_account_ram_bytes; ram_delta += 2*config::billable_size_v ; ram_delta += owner_permission.auth.get_billable_size(); ram_delta += active_permission.auth.get_billable_size(); resource_limits.add_pending_ram_usage(name, ram_delta); resource_limits.verify_account_ram_usage(name); } void resource_limits_manager::initialize_account(const account_name& account) { _db.create ([&]( resource_limits_object& bl ) { bl.owner = account; }); _db.create ([&]( resource_usage_object& bu ) { bu.owner = account; }); } /** * Every account that authorizes a transaction is billed for the full size of that transaction. This object * tracks the average usage of that account. */ struct resource_limits_object : public chainbase::object { OBJECT_CTOR(resource_limits_object) id_type id; account_name owner; bool pending = false; int64_t net_weight = -1; int64_t cpu_weight = -1; int64_t ram_bytes = -1; };
第二種:cleos create account 方式創(chuàng)建賬號,調用的是eosio的默認合約,但該方式在eosio 部署了eosio.system后不可用。 因為默認合約被替換掉。eosio的默認合約是來自源碼提前定義好的。
具體的abi信息在:libraries/chain/eosio_contract_abi.cpp,libraries/chain/eosio_contract.cpp。
跟第一種一樣,同樣是將資源的使用權設置為無限。 下一次再介紹eosio默認合約的形成原理,以及調用流程。
/** * This method is called assuming precondition_system_newaccount succeeds a */ void apply_eosio_newaccount(apply_context& context) { auto create = context.act.data_as(); try { context.require_authorization(create.creator); // context.require_write_lock( config::eosio_auth_scope ); auto& authorization = context.control.get_mutable_authorization_manager(); //判斷公鑰是否合法。 EOS_ASSERT( validate(create.owner), action_validate_exception, "Invalid owner authority"); EOS_ASSERT( validate(create.active), action_validate_exception, "Invalid active authority"); auto& db = context.db; auto name_str = name(create.name).to_string(); //判斷account name的合法性 EOS_ASSERT( !create.name.empty(), action_validate_exception, "account name cannot be empty" ); EOS_ASSERT( name_str.size() <= 12, action_validate_exception, "account names can only be 12 chars long" ); // Check if the creator is privileged //只有eosio才能創(chuàng)建eosio.為前綴的賬號。 const auto &creator = db.get (create.creator); if( !creator.privileged ) { EOS_ASSERT( name_str.find( "eosio." ) != 0, action_validate_exception, "only privileged accounts can have names that start with "eosio."" ); } //判斷用戶名是否存在。 auto existing_account = db.find (create.name); EOS_ASSERT(existing_account == nullptr, account_name_exists_exception, "Cannot create account named ${name}, as that name is already taken", ("name", create.name)); const auto& new_account = db.create ([&](auto& a) { a.name = create.name; a.creation_date = context.control.pending_block_time(); }); db.create ([&](auto& a) { a.name = create.name; }); for( const auto& auth : { create.owner, create.active } ){ validate_authority_precondition( context, auth ); } const auto& owner_permission = authorization.create_permission( create.name, config::owner_name, 0, std::move(create.owner) ); const auto& active_permission = authorization.create_permission( create.name, config::active_name, owner_permission.id, std::move(create.active) ); context.control.get_mutable_resource_limits_manager().initialize_account(create.name); int64_t ram_delta = config::overhead_per_account_ram_bytes; ram_delta += 2*config::billable_size_v ; ram_delta += owner_permission.auth.get_billable_size(); ram_delta += active_permission.auth.get_billable_size(); context.trx_context.add_ram_usage(create.name, ram_delta); } FC_CAPTURE_AND_RETHROW( (create) ) }
跟第一種一樣,同樣是將資源的使用權設置為無限。 下一次再介紹當沒有部署eosio.system合約時,eosio默認合約的形成原理。
第三種:當部署eosio.system合約時,創(chuàng)建賬號都必須使用該合約的newaccount的action。 值得一提的是用第三種方式創(chuàng)建時,第二種方式的apply_eosio_newaccount也會執(zhí)行。
void native::newaccount( account_name creator, account_name newact /* no need to parse authorities const authority& owner, const authority& active*/ ) { //當creator 不是eosio時,需要判斷創(chuàng)建者的資源以及低于12個字符的名字是否通過拍賣。 if( creator != _self ) { auto tmp = newact >> 4; bool has_dot = false; for( uint32_t i = 0; i < 12; ++i ) { has_dot |= !(tmp & 0x1f); tmp >>= 5; } if( has_dot ) { // or is less than 12 characters auto suffix = eosio::name_suffix(newact); if( suffix == newact ) { name_bid_table bids(_self,_self); auto current = bids.find( newact ); eosio_assert( current != bids.end(), "no active bid for name" ); eosio_assert( current->high_bidder == creator, "only highest bidder can claim" ); eosio_assert( current->high_bid < 0, "auction for name is not closed yet" ); bids.erase( current ); } else { eosio_assert( creator == suffix, "only suffix may create this account" ); } } } user_resources_table userres( _self, newact); userres.emplace( newact, [&]( auto& res ) { res.owner = newact; }); //將賬號資源初始化為0,不購買資源無法進行相關動作 set_resource_limits( newact, 0, 0, 0 ); }
文章版權歸作者所有,未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉載請注明本文地址:http://systransis.cn/yun/24614.html
摘要:最近筆者在寫完智能合約,想要寫一些測試案例,但是自帶的單元測試用起來不是很方便。是基于的智能合約測試框架,它的實現(xiàn)方式其實就是去調用來與端進行交互,利用的單元測試工具來做測試,的使用讀者可以自行去了解哈,這里筆者就不贅述了。 最近筆者在寫完智能合約,想要寫一些測試案例,但是 eos 自帶的單元測試用起來不是很方便。平常用 cleos 測試的體驗感其實挺不錯,所以筆者設想有一種是用 cl...
摘要:最近筆者在寫完智能合約,想要寫一些測試案例,但是自帶的單元測試用起來不是很方便。是基于的智能合約測試框架,它的實現(xiàn)方式其實就是去調用來與端進行交互,利用的單元測試工具來做測試,的使用讀者可以自行去了解哈,這里筆者就不贅述了。 最近筆者在寫完智能合約,想要寫一些測試案例,但是 eos 自帶的單元測試用起來不是很方便。平常用 cleos 測試的體驗感其實挺不錯,所以筆者設想有一種是用 cl...
摘要:引言給迷失在如何學習區(qū)塊鏈技術的同學一個指引,區(qū)塊鏈技術是隨比特幣誕生,因此要搞明白區(qū)塊鏈技術,應該先了解下比特幣。但區(qū)塊鏈技術不單應用于比特幣,還有非常多的現(xiàn)實應用場景,想做區(qū)塊鏈應用開發(fā),可進一步閱讀以太坊系列。 本文始發(fā)于深入淺出區(qū)塊鏈社區(qū), 原文:區(qū)塊鏈技術學習指引 原文已更新,請讀者前往原文閱讀 本章的文章越來越多,本文是一個索引帖,方便找到自己感興趣的文章,你也可以使用左側...
摘要:項目版本微信的支付邏輯與支付寶的支付有一些差別。調用微信支付不同接口需要的參數(shù)會有差別。調用客戶端的方式查看微信文檔掃碼支付返回了一個地址??芍苯臃湃胛⑿诺耐瓿烧{用。 payment 項目2.0版本 微信的支付邏輯與支付寶的支付有一些差別。為了讓客戶端忽略這些差別,統(tǒng)一調用。本sdk做了對應處理。 # SDK調用 微信支付不同接口需要的參數(shù)會有差別。請大家在使用接口時,仔細查看文檔。...
摘要:如果一旦加密算法泄露了,攻擊者可以在本地建立一個實現(xiàn)了登錄接口的假冒父應用,通過綁定來把子應用發(fā)起的請求指向本地的假冒父應用,并作出回應。 原文鏈接:BlueSun | 單點登錄的三種實現(xiàn)方式 單點登錄SSO(Single Sign On)說得簡單點就是在一個多系統(tǒng)共存的環(huán)境下,用戶在一處登錄后,就不用在其他系統(tǒng)中登錄,也就是用戶的一次登錄能得到其他所有系統(tǒng)的信任。單點登錄在大型網(wǎng)站里...
閱讀 1368·2021-11-25 09:43
閱讀 1931·2021-11-12 10:36
閱讀 6131·2021-09-22 15:05
閱讀 3508·2019-08-30 15:55
閱讀 2056·2019-08-26 14:06
閱讀 3671·2019-08-26 12:17
閱讀 537·2019-08-23 17:55
閱讀 2482·2019-08-23 16:23