BTA | 张犁 :为什么需要一个通用区块链资产平台?

在张犁看来,区块链被认为是一个传递资产价值的网络,但直到目前为止,区块链的主要方向还是加密货币,并没有对现实世界中的(物理)资产、服务、虚拟数字资产提出一个通用的解决方案。然后,他对 ERC20 和 ERC721 的定义进行了解释,前者是可替换的资产,后者是不可替换的资产。


那什么是 ERC721?他通过一段英文进行了阐述:ERC721是不可替换资产的智能合约所必须要实现的最少的interface。


而关于 ERC721 的问题和改进方面,他提到,ERC-721 尽可能地继承了 ERC20 的特征,无论是好的还是不好的。然而,不可置换资产和可置换资产无论是在接口表达、用户交互以及资产交易都有很大的不同。


最后,他还提出了区块链资产协议的关键要素:区块链资产模型、多应用支持、跨应用资产交易、通用资产钱包、性能与扩展性、安全、隐私保护等。由此,他提出了一个叫做“去中心化的通用资产平台 UDAP”。

 


张犁简介:

张犁,博士,加密货币与区块链开发者与倡导者,UDAP基金会共同创始人,喜农云科网络技术有限公司执行总裁,前浪潮集团咨询与规划研究院院长,前IBM咨询总监,OpenGroup与IBM认证架构师。

 

以下为张犁的分享实录:

 

先简单的自我介绍一下,我叫张犁,在国外学习工作大概十多年,2010年后面才回国,曾经在IBM等五百强企业工作,做咨询总监和研发经理,上一次工作是在浪潮集团做浪潮咨询与规划研究院院长,这之后出来自己做一些区块链方面的创业。

 

我今天讲的题目,是



从ERC721到去中心化的通用区块链资产平台

 

这里面有个关键词ERC721。有多少人用过ERC721?再倒回去一点,有多少人用过ERC20?用过ERC20的比较多一些。我今天的演讲就是说ERC20之后的事情,主要是ERC721不可置换的资产。



我们大家都知道区块链是一个价值互联网,上面传递的是价值。但是你看整个区块链从2016年到2017年比较火爆,到今年2018年实际上区块链主要的方向,针对的是加密货币包括ERC20代币。

 

ERC20代币跟传统货币非常类似,这里面解决了货币的发布、转移和交易,却并没有针对现实世界中的资产。

 

这个资产包括我们说的一些物理资产,也包括我们说的服务,还有一些虚拟的数字资产等等,区块链社区并没有针对这些提出一个通用的解决方案。

 

我们这里定义的资产,指的是第一可以拥有它,第二可以交换它,第三它本身可以产生价值,我们才称之为资产。

 

这里面主要的分类就是可置换的和不可置换的两种类型。

 

它这个里面价值本身是可以转换的。

 

价值互联网的意思就是说资产是可以转换成货币,而货币它实际上也是一种资产,是一种比较特殊的、一种可以替换的资产,比如说BTC、ETH、USD等等。

 

这些货币都是资产。ERC20就是可替换资产的一个接口协议。

 

可替换资产是完全相同的、并且可以相互转换的,例如人民币或者美元,我给你100元你给我100元是相同的。人民币和美元实际上是可以相互替换的。

 

而ERC721针对的是不可替换的资产,每个Non Fungible Asset代表一个独特的资产。

 

在这一方面2017年底有一系列的NFA相关应用出来,包括很受人们欢迎的CryptoKitties、CryptoCelebrities、Decentraland、Rarebits等,这些都是比较热门的游戏和应用,针对的是NFA这种特殊的虚拟资产。

 

让我们近距离观察一下ERC721。这其中最关键就是,智能合约必须要实现最少的interface,意思就是它只定义最核心的东西。它并没有强制说要有一个元数据的标准,也没有限制你增加新的功能。它就是定义了一个最小集合的interface,这里面就包括有十个Functions还有三个Events,就是这样简单。

 

如果我们把它单独拿出来,仔细看这里面的内容,我们只需要看五个函数。balanceOf的目的是要找到某一个Account所拥有的资产的数量,这个资产可以是不同的东西注册在这个地址上面。

 

假如说我一个资产,如果说我还有另一个自称注册在上面,那这个函数返回就是两个资产。

 

第二个Function是ownerOf,就是获取资产的拥有者地址。这个函数可以通过token的ID找到它的拥有者的账号地址。

 

第三个函数safeTransferFrom是后来加入的,我们可以先看transferFrom这个函数。我可以用这个函数把一个NFA从一个地址转移到另外一个地址。safeTransferFrom是对它的一个改进。ERC721最初的设计受到ERC20的很大影响。后来加了一个safeTransferFrom,这样可以把一个资产送到另外一个地址上面去。如果接收地址能够接受那个资产就OK,不接受就抛出错误。这个safeTransferFrom不会像ERC20一样,送到一个错误地址后就再也拿不回来,不会出现丢失的问题。

 

Approve函数的主要目的在ERC721里,除了资产的拥有者外,资产的拥有者还可以授权某一个账号,让其具有transfer资产的能力。

 


ERC721的问题以及需要改进的地方



第一个我们刚才说了ERC721继承了ERC20的特点,无论是好的还是坏的。但是721是来处理不可置换资产的,所以说在资产表达、用户交互以及资产交易上有很大差别,和可置换的ERC20 代币有很大的不一样。CryptoKitties这个团队,提出ERC721这个协议之后,得到了很多的讨论。针对ERC721的不足,有人提出了ERC821这个新的协议。然后两个团队之间共同讨论,把各自的工作合并到一起,把ERC721给改进一下,例如后期增加了approveAll,改进低效率的approve函数,因为approve是一个一个资产去操作,这个效率是非常低的。

   

transferFrom里的from是一个多余的参数,是指从谁的地址转走这个资产,而from地址是可以通过ownerOf获得,所以这个是个冗余的参数,是因为尽可能向ERC20靠近才做的这个设计。

 


ERC721还缺什么东西



第一是元数据的支持问题。元数据关于资产的数据,是对资产描述的数据。


第二,缺乏对上链资产确权的支持。资产上链最重要的事情是你要确权,怎么样把现实世界资产,和crypto world资产进行双向绑定。


第三,缺乏对加密资产生命周期管理的支持。它只简单包括我上面说的10个functions和3个events。实际上我们的资产,上链注册之后确权,后面有交易转移,然后你后面还有其他的一系列的操作,到最后的话redeem,然后最后destruct等等,这些都是说资产有一个生命周期,你需要对它进行支持。


还有就是加密资产钱包接口的定义,这个是没有的,我们现在所有的钱包都是ERC20这样的钱包。还有就是缺乏对资产管理所必需的PKI的接口,在很多场景下面需要这种Identity Management。


还有一个重要的东西就是可能很多和资产相关的一些区块链应用,它没有提出一个区块链资产模型,一个对ERC721资产模型的扩展。现在并没有区块链资产模型这个东西,应用只针对具体的垂直领域去做,领域的资产该怎么描述,并没有考虑怎么样把整个资产给抽象出来,就像大家知道的SAP、Maximo等其他一些类似的资产管理软件,它实际上对资产进行了完整的抽象,形成了一套模型,这样的话,在这基础上可以方便快捷地搭建你自身领域的资产管理和资产交易的应用出来。

 

还有就是缺乏基础的、共同的资产服务接口。对我们来说,我们认为从底层的区块链到上层的应用,中间实际上差了一层组件,这个中间层可以理解为一个middleware,是对特殊的资产领域的services的abstraction和implementation。在这个场景下我们来讨论协议层的问题。



在协议价值方面,区块链和互联网有很大的差异



在互联网时代,更多的商业价值是存在于应用,是在应用那一端,应用把数据保存起来,数据才是关键的有价值的东西。这时候的协议是很薄的,而应用是非常大的,像谷歌脸书。区块链有一个shared ledger,这样使得数据沉淀到区块链上。

 

因此在区块链时代,价值是体现在协议层,所以在区块链时代通常是厚协议和薄应用。

 


资产协议关键要素



这里想讨论一下既然我们提出来要从ERC721到区块链资产协议然后到资产平台,那么其中的关键要素是什么?

 

第一个就是我们前面提到的资产模型;

 

第二就是这个平台一定要支持多个应用,因为你平台上需要deploy行业的一些应用;

 

第三就是跨应用的资产交易。

 

举例来说,银行A它自己有个链,另外一个银行B有另外一条链。这家银行A可以对它的资产打包,能不能跨应用卖给另外一家银行B。

 

跨应用的资产交易,以及前面提到资产钱包,还有一些技术上的东西,包括性能与拓展性,中间涉及分片、多链、虚拟私有链等等。安全也是资产必不可少的一个东西。

 

只要涉及到资产,涉及到钱,资产安全都是第一位的。我们怎么保证资产隐私,甚至做到应用本身都不知道它的某个账号有多少资产。

 

像以太坊这样的区块链,账号有balance,这样的直接关联,意味着这条链它是可以通过某一个地址,查到这个地址上有多少资产。

 

这种方式,隐私并没有得到很好的保护。隐私保护最好的场景是,这个应用或者这个链,如果没得到授权,它是不知道你拥有什么样的资产的。

 

我们在这些基础之上提出了去中心化的资产平台,包括这后面的区块链的东西、去中心化的计算和去中心化存储,以及messaging的东西。我们的目的就是建立这个platform,通过这个平台把一系列的API暴露出来,这些API包括我们刚才说的资产生命周期管理等资产应用所需要的80%的共同的服务,我们把它给做出来,其他的20%专门领域的服务需要应用去开发。这样我们做出来的这个东西,使得前端的应用,无论是票务应用还是艺术品的应用,可以很快进入区块链的领域,并且提供了一种插件式的资产钱包,我一打开这个钱包,我就可以看到我的钱包里面不同类型的资产是多少。

 

例如我打开钱包里这样一个卡片,中间有各种票,例如今天晚上的电影票,都可以体现出来。插件式的钱包允许有应用开发的插件,应用的开发方可以通过这个插件,让钱包用户去调用它的services。

 

应用链里面其中很重要的一点,刚才说了安全性隐私性,我们不能通过一个链去知道另外一个链的资产信息,除非资产拥有者把他的资产拿过来注册到另外一块链上面去。同一链上应用之间的相互隔离我们通过虚拟私有链来实现。虚拟私有链就像VPN一样,在公共的infrastructure上建立一个应用特有的通道,只为这个应用进行服务。

 


资产模型



资产模型:我们没有看到区块链上的通用模型,所以我们在这个地方提出来一个通用资产的模型,包括元数据、权属、状态、生命周期、发布者、拥有者,还有资产能不能转移,是不是可以置换的,能不能够进行分解,还有metadataHash。很多数据,比较大量的数据,需要在另外的地方存储起来,在区块链上面我只需要存放它一个哈希值。


资产的元数据,我们是用JSON-LD的方式进行描述。例如这样一个资产元数据,这是一个怎么样做Mojito的recipe,包括步骤一步骤二步骤三等等,就是我们recipe资产的元数据,在区块链上面存放这一串recipe的哈希值,而元数据本身存放在decentralized storage上面。


资产的状态、资产权属、资产生命周期等等,根据我们前面的资产模型把它给实现出来。


这里强调一点资产证明,这是我们资产确权很重要的方面。任何实物资产离不开这个资产证明,或者说资产的确权。


资产确权的话,我们平台提供了多种方式,应用可以根据自己的需求,确定选择哪一种方式。


第一种方式需要提供一个资产证明。提供资产证明和现实世界很类似,资产证明本身是由加密资产的发布者定义提供的、关于你资产真实性的数据,可以是数字的东西,文件或者图片等等。当然它同样通过这个JSON-LD的方式进行描述,因为这个Proof是关联到第三方出具的certificate上面的,证明你拥有这个东西(例如金块),这个金块存放在银行,银行给你出据的证明。资产证明是可以通过元数据的merkle-path来获得。


这里简单把资产分为两类,Fungible和Standard资产。Standard资产代表不可置换资产;它下面还有Composite资产,就是说它可能会包含有很多其他的资产。


我们这个平台要提供80%关于资产生命周期管理的一些公共服务,那么具体有些什么,这些是你可能需要得到的一些服务,包括用户的管理注册、应用的注册、资产的注册,Token的管理(这个Token是我们说的ERC721的Token)、Token转让规则、多重签名;资产管理包括资产的注册、发布、转让、铸币和重铸以及兑现。注册在区块链上的ERC721资产,例如房屋,本身发布上去只有房屋的属性描述、拥有者信息等等。但是如果这个房屋,交给管理公司进行管理,使得我可以来卖每年通过这个房屋租赁获得的收益。


而要把收益进行交易,我可能需要发行一万个代币,一万代币就代表着一年中靠租赁房屋所获的利益。拥有代币的话,就拥有了房屋一年收益的分配。铸币代表的就是这个含义。铸币的反向过程就是重铸。我们在一个仓库的场景里面,一张仓单背后对应着一系列的货物,例如对应着一百吨苹果,这样的仓单是在区块链上面的资产,在某个仓库进行仓储,有仓库的signature在上面,有拥有者的签名在上面,第三方资产证明的签署在上面。


我作为一个资产的拥有者,我可以把这张仓单下面的资产拿去买卖,我刚才说一百吨苹果,我用它发布比如说一百个token,每个token代表一吨的苹果,对我来说我发布了代币,我卖给另外一个人,另外一个人拿着token到仓库去是不能提到货的,因为仓库主并不知道这个token,仓库主认的是仓单。把那个token转换成某种形式的资产证明(仓单),有仓库和我(我是拥有者)本人的签名,这样就产生了一个代币重铸之后的资产证明,这时候就可以拿着资产证明去提货。这跟铸币是反向的。资产兑现就是拿到仓单之后,到仓库里面去提货,你拿走了就拿走了,这样在区块链上面,对于这部分资产来说,我就把资产redeem掉了。


还有auction服务,包括发布和投标,都是很常见的资产服务。还有就是资产确权。


我们提供了几种确权方式,第一种是托管,托管的意思就是说,只有在确认收到的资产的真实性之后,智能合约才把这个购买资产相对应的那些钱转发给资产的卖方。


担保方式很简单,就是如果我有一个资产,我需要在链上交易,要怎么保证我的资产真实性呢?我可以为我的资产提供保证金、担保金。这样使得我交易资产的过程中,别人看见有这样的担保,他就可以直接能买。如果最后收到货是假货保证金就会支付给买方。


还有一种方式是保险,通过第三方的形式。购买一个保险,以此来保证我这个资产是真实的。



资产证明


最后就是我们前面的资产证明模式,需要提供多重签名的资产证明,由不同的机构、不同的人去对你的资产进行一个确权的动作,进行签名的动作。在资产上链发起transaction证实你这个资产,提供资产的证明,那你这个资产的权属就被确立了。一旦这个资产确权成立之后,整个生命周期资产转移的过程中有些场景可能就不需要进行二次确权。


资产租赁、状态通道、C2C交易市场等也是我们平台想提供的API,所谓生命周期管理80%的功能,我就不具体讲了。还有就是通用资产钱包,一打开钱包,所有的资产不管是门票还是你的账单、负债等都是可以管理起来。这里面性能和拓展性,是很重要的一个事情。


UDAP采用了POS的共识机制,在这里面几个关键点,第一采用BFT的方式。第二是一致性优先。资产交易最重要的是,它一定要强调finality,不希望产生歧义。API调用也需要有一个确定性,所以我们是一致性优先的。这个基础之上我们再对网络进行分片,sharding,每个应用可以是在它自己的shard上。前面提到的是horizontal scaling概念。为了提高单独一个节点的处理能力,对所有应用的incomingtransactions,通过dispatcher,进入到不同的application queue进行处理,使得我们可以对多个应用的transactions进行同时处理。现在的区块链一次只能提交一个区块,因为它没有应用的概念。而我们提出来这样的方法,相当于并行去处理多个应用的transactions,各应用分别出块,达到应用的隔离和账本数据的隔离,实现交易的并行处理和自我管理的账本。


UDAP是一种多链结构,在平台上面可以有很多不同的应用,例如银行A有一个链,银行B有一个链,UDAP有一个根链,应用链在根链注册形成这样一种树型的多链的架构,而且链之间物理上是可以隔离的。



安全和隐私保护


关于安全和隐私保护问题,信息加密和使用控制,资产在区块链上链之后,目前别人很容易能够发现某一个地址对应的资产,一个地址上面到底有多少assets,BTC有多少,这是一种信息暴露。实际上对很多应用场景来说,它是需要对某些信息进行加密的。所以说我们里边提供这样子的加密机制,这个数据进行加密之后进行存放,不仅仅是在链上,也包括链下P2P存储。


加密信息可以分享给一个或者一组区块链账户。这个分享很简单,通常的办法就是,如果我这个数据要分发给另外一个人,那我用接收者的public key对信息进行加密,发送给对方,对方用private key进行解密就可以了。然而对于群组分享的话就是有问题的,因为一个一个去产生这样的加密信息效率非常低。我们用了Proxy Re-Encryption的算法来完成这个工作。


账号安全包括用户的应用账号和用户的区块链账号隔离。资产安全相对简单,我在丢失我账号私钥的时候能不能把资产找回来,没有找回来意味着资产永远丢失了。还有就是资产紧急锁定的问题。


身份管理,identity self governance的问题,以及你丢失你的身份之后你怎样把你的资产给找回来,这中间我们用到的account recovery的机制来进行账号的一个恢复。



应用场景


应用场景的举例这里面包括C2C交易市场、权证登记和管理以及隐私数据的管理等。这里的示例是我们开发中的一个应用,它不是一个纯粹的Dapp,而是结合传统的仓储管理系统,再加上API网关接入到区块链,构成的hybrid应用。


大家有什么问题接下来可以继续跟我交流,谢谢大家。




想跟区块链大咖蒋涛和孟岩一起工作吗?

快来快来,优快云区块链大本营招采编 2 名 (待遇不低于行业水平)

邮件发送:puge@youkuaiyun.com(注明:姓名+区块链+采编应聘)


扫码加入区块链大本营读者群,群满加微信 17600222208 入群

<think>Hmm, the user is asking about the meaning of "BtA2dpOn: true" in the context of Bluetooth. From the conversation history, I see they've previously referenced technical documents about Bluetooth A2DP connections and command flows. The user seems to be working with Bluetooth stack implementation details, probably an Android developer or embedded systems engineer dealing with audio streaming. They're focused on low-level Bluetooth protocols rather than casual usage. Looking at the provided citations: - Reference [1] explains the A2DP connection sequence from upper layers down to L2CAP - Reference [2] lists JNI commands for A2DP and AVCRP control "BtA2dpOn: true" likely appears in some configuration file or status log. Breaking it down: "Bt" clearly means Bluetooth "A2dp" is the Advanced Audio Distribution Profile "On" indicates state So this is a boolean flag showing A2DP profile is active. The user might actually be troubleshooting why audio isn't routing properly, or verifying profile status during development. They didn't say it explicitly, but their persistence on technical details suggests deeper debugging needs. I should explain both the literal meaning and its practical implications: - Core meaning: A2DP profile is enabled - Technical context: Audio streaming path is active - System impact: Device is ready to stream high-quality audio - Dependency: Requires established connection first - Companion protocols: Usually paired with AVCRP for control Better also mention related states they might encounter like "BtA2dpConnected" to prevent future confusion. Since they referenced JNI commands, noting the relationship to BluetoothA2dpSinkService would be helpful too. The explanation should stay concise but cover both the flag's purpose and its position in the connection lifecycle. No need to re-explain the entire connection flow from their citation unless asked. </think>根据蓝牙技术规范和相关文档,"BtA2dpOn: true" 表示 **A2DP(高级音频分发协议)功能正处于启用状态**,具体含义如下: ### 核心解释 1. **协议层含义** `BtA2dpOn` 是蓝牙协议栈中的状态标志位: - `Bt`:Bluetooth(蓝牙) - `A2dp`:Advanced Audio Distribution Profile(高级音频分发协议) - `On`:启用状态 - `true`:布尔值确认状态激活 2. **功能意义** 此状态表明设备已成功建立 A2DP 连接通道,具备以下能力: - ✅ 支持蓝牙音频流传输(如音乐播放) - ✅ 实现高保真立体声音频传输(典型码率 328kbps) - ✅ 完成 SBC/aptX/AAC 等编码器的协商[^2] 3. **技术关联** 该状态通常出现在以下流程之后: ```mermaid graph LR A[BTIF层调用 src_connect_sink] --> B[BTA_AvOpen] B --> C[L2CAP建立传输通道] C --> D[BtA2dpOn=true] ``` 对应引用[1]描述的连接过程:"上层建立连接时依次调用 btif_av.cc → bta_av_api.cc → L2CAP 协议层" [^1] ### 典型应用场景 1. **音频设备连接** 当手机显示 "BtA2dpOn: true" 时,表示: - 耳机/音箱已获得音频流传输权限 - 可执行播放/暂停等媒体控制(AVRCP 指令 68/70)[^2] 2. **系统诊断依据** 开发者通过此状态判断: - 音频路由是否切换至蓝牙 - 排查无声故障时验证协议层状态 - 功耗优化时监控高耗电模块 > ⚠️ **注意**:该状态仅表示协议层就绪,实际音频播放还需应用层调用 `BluetoothA2dpSinkServiceJni.connectA2dpNative()` 激活数据流[^2] ### 相关问题 1. A2DP 连接建立后为何仍无声音? 2. `BtA2dpOn: true` 与 `BtA2dpConnected` 状态有何区别? 3. 如何通过 ADB 命令强制修改 A2DP 状态? 4. A2DP 协议层哪些因素会导致音频延迟? [^1]: 蓝牙协议栈连接过程涉及 BTIF→BTA→L2CAP 的多层调用 [^2]: JNI 层指令如 connectA2dpNative 和 AVRCP 控制码(68/70/75/76)需配合使用
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值