EOS跨链通信原理与设计

区块链资讯BOSCORE团队2019-03-09 00:53:06  阅读 -评论 0

本文将介绍IBC技术原理,并对BOSCORE团队开发的IBC合约及插件进行深入介绍。

为了实现两条EOSIO体系区块链间token的跨链转移,首先需要解决两个难题,1.轻客户端如何实现,2.如何确保跨链交易的完整性和可靠性, 如何防止双花和重放攻击。下文均以EOS主网和BOS主网为例进行说明,但本文档适用于任何两条EOSIO体系的区块链。

一、术语

BOSIBC:是指BOSCORE技术团队开发的IBC合约及插件。

二、关键概念及数据结构

· Simple Payment Verification (SPV)

简单支付验证技术最早在中本聪的比特币白皮书中提出Bitcoin,用于验证一笔交易存在于区块链中。 SPV client存储着连续的区块头,但没有区块体,因此只需占用很小的存储空间。当获得一笔交易和这笔交易的Merkle path后,可以验证这笔交易是否 存在于区块链上。

· Lightwight client (lwc)

轻客户端,即SPV client,即由区块头组成的一条轻量的链。

· Merkle path 默克尔路径。为验证一笔交易是否存在于某个区块中,只需要提供交易原始数据和交易在所在区块的merkle path,而无需提供整个区块体,通过计算merkle path并和区块头中 记录的merkle root对比,若相等,则说明此交易存在于此区块中。merkle path也被称为merkle branch。

· Block Producer Schedule

BP Schedule是基于DPOS机制的EOSIO体系公链用于决定生产区块权利的技术,新的BP Schedule是由上一批BP Schedule包含的Block Producers认证通过后生效 以此确保严格的BP权利交接,在轻客户端中跟随对应主网的BP Schedule是IBC系统逻辑的一项核心技术。

· forkdb

EOSIO节点在运行时,有两个底层的db用于存储区块信息,一个是blog即block log,用于存储不可逆区块,一个是forkdb,用于存储可逆区块。 forkdb存储的是当前区块链最顶端的一部分区块信息,一个区块首先要被forkdb接受才能最终进入不可逆区块,IBC系统在合约实现的轻客户端主要参考了forkdb的逻辑。

三、轻客户端

为了解决跨链问题,首先要解决的是轻客户端如何实现的问题。

1. 轻客户端运行在哪里合理,合约中还是合约外,例如插件中;

2. 若运行在合约中,是实时同步对方链的全部区块头数据,还是根据需要同步一部分区块数据来验证交易,因为如果同步全部区块数据会消耗两条链大量cpu资源。

3. 若运行在合约中,如何确保轻客户端的可信性,如何防止恶意攻击,如何做到完全去中心化,不依赖对任何中继节点的信任;

3.1 轻客户端是否运行在合约中

特币的轻客户端最早是运行在单个节点上(如个人电脑或去中心化比特币手机钱包),用于验证交易是否存,并查看交易所在区块深度。

IBC和去中心化钱包对轻客户端的需求是不同的,去中心化钱包一般运行在个人的手机App上,为用户个人提供交易验证服务,而IBC系统需要的轻客户端 要对所有人公开可查可信,从这个角度看,一个能够获得大众信任的轻客户端只能运行在合约中,因为只有合约的数据是全局一致不可篡改的, 运行在合约外则无法实现一个可信的轻客户端,因此BOSIBC将轻客户端运行在合约中。

3.2 是否同步全量区块头信息

在比特币和以太坊的轻客户端中,会寻找一个起点和后续的一些验证点,轻客户端会同步起点后的全量的区块头信息。比特币每年产生的所有区块的区块头体积仅有4Mb, 按现在移动设备的存储能力,是完全可以容纳的,并且同步这些区块头也不会消耗移动设备大量计算资源。然而EOSIO的情况却很不同, EOSIO每0.5秒一个区块,实际测试可知,每添加一个区块头到合约中需要消耗0.5毫秒cpu,每删除一个区块头需要0.2毫秒,因此每处理一个区块头需要0.7ms的cpu。 假设要同步对方EOSIO公链的全量区块头信息,按现在每个区块总的cpu时间200ms计算,也就是需要一条链全部计算的0.7ms / 200ms = 0.35%才能实时全量同步 另一条链的所有区块头, 按实际全网抵押总量为4亿token计算,如果再cpu繁忙时保证IBC系统正常工作,需要为push区块信息的账户抵押 4亿 * 0.35% = 140万token,这是个很大的数目。又因为EOSIO倡导多侧链的生态,假设未来有多条侧链和EOSIO主网实现跨链,并且侧链与侧链间 也实现了一对多的跨链,按1对10计算,每条链需要维护10个轻客户端,则只为了维护这些轻客户端就需要消耗3.5%的单条链全网cpu,这个比例实在是太高了, 因此需要寻找更合理的方案。

设计跨链通信的过程是一种寻找可信证据的过程,有没有一种方案即不需要同步全量区块信息,又可以保证轻客户端的可信性,EOSIO底层已经为实现这一目的有所准备。 我们先假设,如果BP schedule自始至终不会变化,那么任何时候,当ibc.chain合约中获得一连串的签名验证通过的区块头,比如第n ~ n+336个, 并且有2/3以上的活跃bp在出块,就可以确信第n个区块已经是不可逆的,可以用于验证跨链交易。 然后,就是需要考虑有BP schedule更换的情况了,当出现BP schedule更换时,不在接受交易验证,直到更换完成,处理BP更换时相对复杂的过程,后续会更详细介绍, 因此使用这个方案就可以大大降低需要同步的区块头数量,只有在BP列表更换或有跨链交易时才需要同步区块。

为了实现这一目的,在ibc.chain中引入了概念section,一个section记录的是一段连续的区块头信息,section结构不存储具体的区块头信息,而是记录这一段 区块头的第一个区块编号(first)和最后一个区块编号(last),具体区块头信息在chaindb中存储,每个section都有一个valid值,在没有bp schedule更替的时候, 只要有2/3的活跃BP在出块,并且last - first > lib_depth则认为first ~ last - lib_depth的区块是不可逆的,可以用于验证跨链交易, 当遇到BP schedule 更替,section的valid变为false,不再接受交易验证,直到schedule更替完成,valid重新变为true之后,继续验证跨链交易。

3.3 如何确保轻客户端的可信性

3.3.1 forkdb

1.一个新的区块是如何追加到forkdb的

一个运行的nodeos节点维护着两个底层数据结构blog 和forkdb, blog用于存储不可逆的区块信息,其存储的数据是序列化的signed_block,forkdb用于存储可逆区块信息,其存储的数据是block_state, block_state比signed_block包含更多区块相关信息。一个区块首先要被追加到forkdb,才可能最终变为不可逆区块而移除forkdb进入blog, 一个区块的block_state信息是如何获得的呢,并非生产区块的BP将所生产区块的block_state通过p2p网络传递给其他bp和全节点,p2p网络 只传递signed_block, 当一个节点通过p2p网络接收到一个signed_block后,它会使用此signed_block构建block_state并验证签名 相关函数, 其中需要说明的几个关键点是,1.blockroot_merkle,2.get_scheduled_producer(),3.verify_signee()。

blockroot_merkle

EOSIO在block_state::block_header_state结构中维护了一个blockroot_merkle的incremental_merkle数据,incremental_merkle实际是 一个完整的merkle树的活跃节点,使用incremental_merkle只需维护极少的活跃节点信息即可不断累加并获得merkle_root,是block_state 中使用的一个关键技术。BOSIBC的ibc.chain合约同样使用了此数据结构。

blockroot_merkle从创世区块id不断累加,但是signed_block和blog中并没有这个数据,只有forkdb的每个block_state中记录着当前block的 blockroot_merkle,并且此值被用于计算区块签名。

get_scheduled_producer()

此函数根据一个区块的header.timestamp计算出应该生成此区块的producer_key(见block_header_state::next()),为后续验证签名做准备。

验证签名相关函数如下

digest_type block_header_state::sig_digest()const {

auto header_bmroot = digest_type::hash( std::make_pair( header.digest(), blockroot_merkle.get_root() ) );

return digest_type::hash( std::make_pair(header_bmroot, pending_schedule_hash) );

}

public_key_type block_header_state::signee()const {

return fc::crypto::public_key( header.producer_signature, sig_digest(), true );

}

void block_header_state::verify_signee( const public_key_type& signee )const {

EOS_ASSERT( block_signing_key == signee, wrong_signing_key, "block not signed by expected key",

("block_signing_key", block_signing_key)( "signee", signee ) );

}

验证签名的第一步是获得区块摘要,即sig_digest(),此函数中用到了header.digest(),blockroot_merkle.get_root()和pending_schedule_hash; 第二步是获得签名公钥,即signee(),通过区块的producer_signature和sig_digest()计算BP公钥; 第三步是验证公钥是否正确,即verify_signee(),此函数在block_header_state::next()被调用;验证通过后,一个区块被追加的forkdb中的分支中。

所以在forkdb中每添加一个区块都经过了非常严格全面的效验,核心是包括blockroot_merkle,get_scheduled_producer()和verify_signee(), 在ibc.chain合约完全继承了forkdb严格的效验。

2.forkdb如何处理分叉

当添加一个新的区块导致fordb的head.id和controller_impl的head.id不同时,则重新选择分支。 源码参考eosio::chain::controller_impl的push_block()和maybe_switch_forks();

3.LIB如何确定

EOSIO目前使用的共识方式是dpos,当构造一个区块的block_header_state时会设定required_confs,此值为当前活跃BP数量的2/3+1, 在21个BP的情况下,required_confs为15。每个区块头中都有header.confirmed,用于对前面的区块进行确认,每个区块得到一个确认, 其required_confs会减1,当某个区块的required_confs减少到零时,此区块会被最新区块(即forkdb的head)提名为dpos_proposed_irreversible_blocknum, 当某个区块获得了2/3的BP提名后,其变为不可逆区块,即进入LIB。由于确认的信息是在header中传递的,因此一个区块从产生到进入LIB总共需要 两个2/3轮,也就是 12 *( 14 * 2 ) = 336才会进入LIB,考录到BP每次都是连续出12个区块,只有第一个区块的header.confirmed为非零, 因此当一个BP开始出块时,只有第一个区块会提升LIB,因此实际head和LIB的差距在325至336之间,但是在有BP丢块的情况下,head和LIB的差距可能出现小于 325至336。

4.BP列表是如何更换的

在pow的区块链中,比如比特币和以太坊,是选择算力累加最大的分叉作为主链,一个区块只有包含一定的算力才有可能被认可,最终变为不可逆。 而在以dpos为共识算法的EOS中,区块被认可的标记是BP签名,因此BP列表在EOSIO中具有至关重要的地位。IBC的轻客户端同样需要维护BP列表和BP列表的更换, 因此需要透彻分析BP列表的更换逻辑。

第一步,在系统合约eosio.system的onblock()函数中,系统会每分钟一次尝试更新bp列表update_elected_producers( timestamp ),此函数最终调用 wasm接口set_proposed_producers(),通过一系列检查后,会将新的schedule和当前区块编号存到global_property_object对象中。

第二部,当此区块变为不可逆之后,会在当前的pending区块中设置新的名单header.new_producers,并重置global_property_object对象,当前 pending区块编号会被记录到pending_schedule_lib_num,此时在nodeos日志中可以看到新的名单;具体逻辑参考controller::start_block() // Promote proposed schedule to pending schedule.。 也就是说新的名单从proposed schedule变为pending schedule大约需要经历325至336个区块。从这里开始, 后面区块block_header_state的pending_schedule.version会比active_schedule.version大1.

第三步,当pending_schedule_lib_num变为不可逆后,active_schedule会被pending schedule替换,整个的BP更换过程完成。 从pending schedule出现到其变为active_schedule同样需要经历约325至336区块。

IBC系统的轻客户端同样需要继承forkdb的这些逻辑,才能实现可信的轻客户端。然而,轻客户端是在合约中实现,需要充分考虑合约的特性和限制, 因此在实现细节上,需要做诸多调整。

3.3.2 eosio::table("chaindb"), ibc.chain合约中的forkdb

1.轻客户端(lwc)的LIB如何确定

有两种方案,一种是完全按forkdb的逻辑,维护一整套confirm_count和confirmations等block_header_state相关信息,每添加一个区块 计算一次LIB,这样做的优点是可以准确获得实时LIB值,然而对于轻客户端来说,其关心的是区块已经不可逆,而并非实时的精确LIB值。有没有更简单的方案呢, 根据上述的逻辑,如果有活跃的2/3以上的BP在出块,并且某个区块的深度超过336,则此区块一定是不可逆的,可以用于验证跨链交易;使用这种方案, 可以简化合约中forkdb的复杂度。

ibc.chain合约中表global的lib_depth是一个深度值,当在一段连续的区块头中,某个区块头的深度超过此值时,则认为不可逆,可以用于验证交易了。 此值应该设置多少合适呢,可以设置成336,当轻客户端检查到有2/3以上的BP在出块,则认为深度超过了336的区块是不可逆的。然而在合约中添加和删除区块头 是非常耗cpu的,实际测试可知,每添加一个区块头需要消耗0.5毫秒cpu,每删除一个区块头需要0.2毫秒,因此每个区块头需要0.7ms的cpu。 是否会出现主网巨大波动,导致没有进lib的区块全部回滚呢,这是有可能的,实际也发生过,因此要必须确保一笔跨链交易所在区块进入lib,再开始处理。 插件在此时可以起到一定的作用,在BOSCORE技术团队研发的ibc_plugin中,设置了参数,只处理一定深度内的跨链交易,这样,插件中的深度和合约中的深度相加 超过336即可。这只是BOSIBC初期的做法,目的是避免消耗大量cpu,后续可能会考虑将合约中的深度设置为336,从而完全不依赖中继的深度,然而无论是插件 还是合约中增加深度值,都会直接延长跨链交易到账时间,从而影响用户体验,因此需要根据实际情况确定一个合理的值,从而即保证足够安全又不失良好的用户体验。

2.表chaindb

表chaindb是ibc.chain合约中的forkdb,ibc.chain合约中没有blog结构,和eosio中forkdb使用的block_header_state不同,chaindb进行了大量精简,只保留了 block_num、block_id、header、active_schedule、pending_schedule、blockroot_merkle、block_signing_key7个数据,又因为 bp schedule需要占用大量空间,因此在另外的表prodsches中存储实际schedule信息,在chaindb中用id引用,以节省内存占用和wasm cpu消耗。

3.轻客户端的创世区块

轻客户端需要一个可信的起点,此起点是轻客户端的创世区块头,后面所有区块头的验证都是基于创世区块头的信息。 创世区块头需要block_header_state中的blockroot_merkle,active_schedule和header信息,才能验证区块签名。 源码为chain::chaininit(),最重要一个限制是,创世区块头的pending_schedule必须和active_schedule相同,因为其不同意味着 此区块是bp列表更替过程中的一个区块,如果使用更替过程中的区块,需要同步后续的区块,直到active_schedule被pending_schedule替换, 增加了复杂度,因此这样的区块不适合作为创世区块。

4.轻客户端是如何添加新区块的

轻客户端添加header的方式和和eosio的forkdb非常类似。源码见ibc.chain的chain::pushheader()。 第一步,通过区块编号验证是否能够连接到最新的section 第二部,是否需要处理分叉,删除旧数据。在ibc.chainz中不会同时保存多个分支,而是以后者替代前者的方式实现对分叉的处理。 第三步,通过区块id验证是否能够连接到最新的section 第四部,构造block_header_state,并验证BP签名

其中最核心的是构造block_header_state,在这个过程中处理的BP schedule的更换,确保有2/3以上活跃BP(见section_type::add())。

5. Section Section是chaindb的核心概念和创新,意思是一段连续的区块头,Section的管理也是最ibc.chain的核心的逻辑。 使用section的目的是降低cpu消耗,只有在BP schedule有变化或有跨链交易时才需要同步一部分区块头。 任何section的起始区块不能是 bp schedule 更换过程中的区块,也就是说,任何一个section的起始区块的pending_schedule.version必须等于 active_schedule.version,并且一个section的起始区块头的active_schedule必须和前一个section最后区块的active_schedule相同, 这样就保证了在任意两个section之间一定不存在BP schedule的更换,每一此BP schedule更换的完整过程必须在某个section中完成,从而确保 section数据的可信性。

四、跨链交易

1. 跨链交易三部曲

一笔跨链交易分为三个过程,下面以将EOS从EOS主网跨链转账到BOS主网为例说明,首先用户在EOS主网发起一笔跨链交易orig_trx,在EOS侧ibc.token合约的 origtrx表中会记录此交易信息,当这笔交易所在区块进入lib后,EOS侧IBC中继(relay_eos)将此交易和交易相关信息(区块信息及Merkle路径) 传递到BOS侧中继(relay_bos);relay_bos构造cash交易并调用BOS侧ibc.token合约的cash接口,如果调用成功, cash函数中会给目标用户发行对应的token;等cash交易所在的区块进入lib后,relay_bos会将cash_trx和此交易相关信息(区块信息及Merkle路径) 传递到relay_eos,relay_eos构造cashconfirm交易并调用EOS侧ibc.token合约的cashconfirm接口,cashconfirm会删除EOS侧ibc.token合约 中对orig_trx的记录,至此一笔完整的跨链交易完成。

2. 跨链失败的交易

跨链交易是可能失败的,比如指定的账户在对方链上不存在,或者由于网络环境恶劣,导致调用cash接口失败,未能成功跨链的交易会被回滚,即原路退还用户的资产, 然而现在的IBC系统是交易驱动的,失败的IBC交易需要等到有成功的IBC交易完成后才会被回滚。(注:后续版本升级会让失败的交易尽快回滚)

3. 如何防止replay攻击,即双花攻击

防止双花攻击分为两个阶段:

1,一笔成功的跨链交易只能执行一次cash,否则会造成重复cash。

2,对于每一个cash交易,必须将其相关信息传回原链执行cashconfirm,以消除合约中记录的原始交易信息,否则会出现即在目的链上给用户发行了token, 又将原链的token退还给了用户。

cash函数是ibc.token的核心逻辑,ibc.token合约中记录着最近执行cash的原始交易id,即orig_trx_id,并且新的cash的orig_trx的区块编号必须 大于或等于所有orig_trx所在的区块编号,也就是说必须按原始交易在原链按区块的顺序进行cash,(执行cash时,原链某个区块内的跨链交易顺序是无关紧要的) ,再结合trx_id检查,可以确保一笔跨链交易只能执行一次cash。

同样,cashconfirm接口会检查cash交易的编号seq_num,此编号必须逐一递增,以确保所有在目的链上的cash交易都会删除在原链上的原始交易记录, 从而确保不会出现双花的情况。

五、插件

插件的作用分为两部分:1,轻客户端同步;2,跨链交易传递。

核心逻辑请参考ibc_plugin_impl::ibc_core_checker()

ibc_plugin主要参考了net_plugin的框架。

六、问答

问:IBC合约的多个action中用到了relay的权限,那么,本IBC系统是否依赖对中继的信任。

答:目前出于安全以及快速功能迭代的考量,特意添加了中继权限,随着功能逐渐完善 BOS IBC 方案会支持多中继机制,以避免单点风险。

验证relay权限处于两种考虑:1,ibc.chain合约使用了section的机制,现在的逻辑不允许为旧的section添加区块,也不允许在一个section前面 添加区块头,如果任何人都可以调用pushsection接口,假设应该push的区块范围是1000-1300,故意捣乱的人可能会抢先push 1100-1300, 从而导致1000-1100无法被push,进而导致一些跨链交易无法成功,(注,此问题会在后续版本中考虑优化);2,考虑到IBC系统承载着 大量用户资产,并且本系统还未经过长期市场考验,因此增加了relay权限,以降低安全风险。

七、升级计划

1. 兼容pbft

2. 以更优雅的方式支持多条侧链&EOS主链互相跨链

3. 支持token以外其他类型数据的跨链

声明:链世界登载此文仅出于分享区块链知识,并不意味着赞同其观点或证实其描述。文章内容仅供参考,不构成投资建议。投资者据此操作,风险自担。此文如侵犯到您的合法权益,请联系我们100@7234.cn

    参与讨论 (0 人参与讨论)

    相关推荐

    中信银行打造“区块链”信用证结算!

    中信银行打造“区块链”信用证结算!

    科技不会改变金融的实质,但却能让金融服务更高效,能让资金供、需方信息不对称的问题更好地解决。近期,中信银行首个区块链项目——基于区块链的国内信用证信息传输系统(简称BCLC)(一期)成功上线,这是国内银行业第一次将区块链技术应用于信用证结算领域。 据中信银行国际业务部总经理助理张栩青介绍,将现在流行的区块链技术应用在国内信用证中,改变了银行传统信用证业务模式,信用证的开立、通知、交单、承兑报文

    中国信息技术部门成立区块链研究实验室

    中国信息技术部门成立区块链研究实验室

    暴走时评:本月初,中国政府对国内的ICO和数字货币交易所的打击在世界范围内引起了强大反响,但政府已经多次声明不会将区块链与数字货币划等号,依然非常重视区块链技术在中国的发展。鉴于中国工业和信息化部成立了一个专门研究区块链的实验室,这一论调也得到了进一步的证实。 虽然中国政府最近在大力打击比特币交易所和ICO,但仍然致力于开发区块链在其他领域的潜力。 据财新网报道,中国工业和信息化部已经成立了一

     分布式账本中的生命科学

    分布式账本中的生命科学

    生物科学是医学领域涉及遗传研究,疾病预防和生活方式治疗(lifestyle treatments)的学科。它已经存在了很长时间,但区块链技术的基础设施应用给该学科提供了重大进步的可能性。 根据Pistoia Alliance进行的2016年6月份高级制药和生命科学领袖调查,83%的受访者表示,他们预计在五年内将全面采用区块链技术。 Pistoia Alliance是一个全球性的非营利组织,致

    区块链vs.核能:日本最大电力公司东京电力(TEPCO)寻求使用区块链减轻对核电的依赖

    区块链vs.核能:日本最大电力公司东京电力(TEPCO)寻求使用区块链减轻对核电的依赖

    东京电力公司 (TEPCO) 对于能源过度中心化的风险可以说绝不陌生。 也许最著名的就是2011年发生的福岛核电站事故,这个日本最大的能源公司如今正在寻求区块链技术来防止这种灾难再次发生。 然而,从使用微型风车的分布式风力发电到用于存储在电力成本低时购买的电力的智能电池,可替代能源项目一直以来都属于个人慈善事业。 然而,TEPCO风险投资部门主管Jeffrey Char认为区块链能够帮助为这

    继证监会发表代币发行声明之后,香港交易所Gatecoin将下线部分ICO币

    继证监会发表代币发行声明之后,香港交易所Gatecoin将下线部分ICO币

    经过一系列监管以及合规审查后,香港交易所Gatecoin将会下线那些被金融监管部门定性为"证券"的代币。 香港加密货币交易所Gatecoin透露,如果在该平台交易的ICO代币在法律上符合"证券"定义,他们就会下线这些代币。据巴比特上月报道,香港主要的金融监管部门证券及期货事务监察委员会(SFC)表达了对ICO这种日渐普及的募资模式的担忧。 尽管ICO中售卖的数字代币通常都被定义为虚拟商品,但

    IBM与超级账本共同加入去中心化身份基金会(DIF),推动创建区块链ID行业标准

    IBM与超级账本共同加入去中心化身份基金会(DIF),推动创建区块链ID行业标准

    IBM与超级账本已经签署协议加入去中心化身份基金会(DIF),这个于今年初成立的联盟旨在帮助推动基于区块链的ID系统的互操作性和标准。 这两个企业区块链大佬加入了这个有各种企业组成的团体,其中包括像微软和埃森哲这样的大企业,还有像Civic和Gem这样的创业公司,以及像uPort和Sovrin这样的开源项目。 DIF执行主管告诉Coindesk说: "这应该是一个信号,表明在这一领域有广泛的

    为打击人口贩卖,牙买加警方盯上了犯罪分子的比特币钱包

    为打击人口贩卖,牙买加警方盯上了犯罪分子的比特币钱包

    作为打击人口贩卖计划的一部分,牙买加警方已经开始行动,锁定了那些试图用比特币和数字支付来掩人耳目的犯罪分子。 越来越多的人口贩卖者都开始转向数字货币来帮助他们进行地下活动并接收非法活动所得,但牙买加警方已经盯上他们了。 牙买加的'大生意' 不幸的是,人口贩卖以及性奴市场规模十分庞大,预计涉资1500亿美元。在牙买加,大约有7000个妇女、儿童以及成年男性被奴役,他们的操控者出售奴役服务的价格

    深圳市将发布《深圳市扶持金融业发展若干措施》,奖励区块链、数字货币等金融创新

    10月9日,深圳市人民政府向各区人民政府,市政府直属各单位印发《深圳市扶持金融业发展若干措施》(以下简称"《若干措施》")。深圳市政府表示,此举是为进一步完善金融支持政策体系,吸引集聚优质金融资源,推动全市金融业可持续均衡发展,加快建设国际化金融创新中心。 《若干措施》共分五大项,33条。内容包括:坚持服务导向,优化金融政策环境;发展金融总部经济,鼓励金融总部企业做大做强;支持金融企业分支机构

    麦妖榜
    更新日期 2019-05-24
    排名用户贡献值
    1BitettFan23907
    2等待的宿命23809
    3六叶树20309
    4区块大康17751
    5天下无双16192
    6linjm122714974
    7lizhen00214933
    8让时间淡忘14390
    9牛市来了11470
    10冷风大q11188
    返回顶部 ↑