首发|发币谁都会,你会发“货”么?是时候用Token干点“正经事”了

2024-02-12 12:20

本文主要是介绍首发|发币谁都会,你会发“货”么?是时候用Token干点“正经事”了,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

零识专访|作者:Sherlock 本期采访对象:中南


为了方便阅读下文,特此做几个定义的解释:

可替代性通证(fungible token):在本文指的是基于区块链技术发行的,互相可以替代的,可以接近无限拆分的token,如各种数字货币,各种ICO token,各种代币。

不可替代性通证(non-fungible token): 在本文指的是基于区块链技术发行的,唯一的,不可替代的,大多数情况下不可拆分的token,如加密猫(CryptoKitties),如token化的门票、token化的实物等……

ERC875:不可替代性通证标准(non-fungible tokenstandard )

加密猫(CryptoKitties)的出现着实火了一把。

加密猫其实是一种token化的不可替代性数字资产。在数字资产的世界里,每只猫背后都只是一个不可替代性通证(non-fungible token),通过编写智能合约,加密猫存在于公链以太坊上,因此,每只猫(其实就是代表每只猫的那一串代码)都会永久存续在链上运行。相对于各种币,猫等不可替代性数字资产就是“货“了。

这是一只“超级稀有”吸血德拉古拉猫

惊艳的原因是我们没有想到一串代码、一张图片能够被标上高得有些夸张的价签。其背后的区块链技术赋予这只猫是世界唯一一只、不会消失、永续存在、可以被交易的特点,其数字化基因还能繁衍后代,配种、繁衍都能产生丰厚的收益……这么说好像稍微能解释它的价格了,但是它纯娱乐的功能还不能体现它的价值。

代码和智能合约是不变的技术,而界面和UI可以重新设定改变,今天被代表的可以是猫,是养成游戏,明天可以是狗、猪、杯子,是其他应用……那串代码的属性和功能不变,因此如果把现实世界的门票设计为一串具有加密货币功能的代码、把一瓶酒植入有代码的二维码、把耳机、电脑、任何你想赋予价值并进行流通交易的实物都实现token化,用token的形式在现实世界中创造、体现、使用,不再是一个简单的养猫游戏,未来会是一个什么样的世界?

“发币”与“发货”的区别

ERC20协议在ICO的风潮下被广泛使用,使用ERC20协议发行的token容易交换和兼容,并且能够在DApps上行使相同功能,token的持有人可以完全控制资产并且跟踪到任何地址任何数量,而且这些token可以用于不同项目和平台。

但ERC20协议本身只能发行可替代性通证(fungible token),用其来代表各种可替代性事物(如钱,证劵,积分,代币等等)。但现实生活中大部分的事物是不可替代的(任何一个物理商品,各种IP,带有唯一属性的权益,任何一个个人等等)。

ERC20无法做到代表现实世界中无法拆分的、独一无二的资产。假设一张门票要以token的形式流通,它必然要有个性化的标记,比如锚定某场演唱会,某个座位、以及这张票归谁,发行方是谁。其次ERC20是不能实现更复杂的功能的。现有的打包、转帐流程比较复杂,如何实现让小白用户像使用支付宝、微信钱包那样轻松,且不必考虑打包时间、如何支付gas?

这就是ERC875要做的。

ERC875协议的研发团队来自新加坡,本期采访对象是团队成员之一张中南,曾在亚太各国管理跨国团队和企业超过7年的,成功帮助360Experience(Ticketbis 3个业务部门之一)进入亚太市场,从零开始到2016年被eBay以1.65亿美金整体(Ticketbis)收购,也是一位连续创业者。主要的技术开发人员张韡武,曾在澳大利亚联邦银行(澳大利亚最大的金融机构)担任区块链构架师,主导了12个区块链项目。超过5年的区块链开发经验,从alt货币设计到交易算法等。 并任职R3全球构架师工作组。

张中南告诉零识区块链,他们的技术交流伙伴之一——欧足联(EUFA)的票务系统供应商已经在私链上测试发行token型门票,欧足联也有计划在19年欧冠决赛期间,全部使用区块链门票, 以提升用户体验,并全方位实现对一二级票务市场的监管。前期主要测验了用户的接受程度,现在他们主要在突破使用公链的技术难点。(有兴趣的可以阅读相关报告https://www.secutix.com/combatting-ticket-fraud-with-blockchain-technology/)如果最后选择在以太坊上面实施的话,采用ERC875标准,现在就可以实现编写智能合约来发行相关门票。

对于其他的物理商品ERC875又有什么价值呢?

把真实世界里面的东西token化真的有价值么?我们知道目前的防伪手段都是防君子不防小人的, 以高档名酒为例,每一瓶酒出厂后都印上一个唯一的二维码,并且匹配一个数字身份证(不可替代性通证non-fungible token),这个token只代表这瓶酒,这个token将随着这瓶酒在渠道内流转,每个节点在获得这瓶酒的同时也必须同时获得这个token,没有收到的话说明肯定是假的,收到token之后可以在本地验证,使用token即可和酒瓶上的二维码进行匹配检查真伪。

在高档名酒这个案例中,商家还可以设置更复杂的功能,比如客户可以直接向厂家做反馈或者其他信息的收集,在有了token的所有权作为身份认证信息,这个白酒的token在钱包中还可以在做一些更复杂的独立应用,通过钱包可以进行调取。除此之外还可以与可替代性资产(以太币、比特币等)进行交易。

还有个案例是关于一个游戏引擎公司。很多游戏都是基于他们的引擎开发的,同时里有内购的都会使用到这个公司的支付插件。这个公司设计了在支付环节将用两层的token来代替,这两层的token都是ERC20发行的可替代性资产,相当于游戏内的代币和支付给开发人员的货币。

如果把ERC875加入开发系统,就可以让所有基于他们引擎开发的游戏都实现这些游戏内的虚拟装备都变成不可替代性通证(non-fungible token),让游戏内这些不可拆分的资产(也就是游戏内的道具装备)都有唯一的代码属性。当所有游戏里的装备都变成了token,那么这些装备将可以实现独立储存、交易……不再局限于某个游戏平台内,流通性大大提升,并且你真正成为了这些装备的主人。

当现实生活中可替代性事物和不可替代性事物都被token化之后,会出现复杂的中间层智能合约来同时调用各种token,这个调用其他智能合约(token)的中间层智能合约会不会把淘宝、滴滴、美团、Airbnb……替代掉,会不会诞生出全新的,我们现在想象不到的产品和服务?这些都是完全可能的。当然前提是我们实现了现实世界的token化,变成一个数字资产世界。ERC875就是可以让任何人在以太坊上面都可以把任何不可替代性事物token化的标准。用ERC20发“钱”,用ERC875发“货”。

回过来看目前已经落地的不可替代性通证(non-fungible token)使用案例,其实CryptoKitties的协议还比较简陋,这也是为什么会出现以太坊网络拥堵问题,交易流程也并不方便,对于小白用户来讲更是“麻烦”了。而区块链技术要迎来规模性爆发必须要有大众用户的支持来实现,我们有必要实现让大众用户即使不理解区块链、以太坊、智能合约的定义都能轻松使用。ERC875针对这点内置了一些先进的协议,让token的发行方可以写出更加用户友好的智能合约。

有时候我们过多地考虑了对用户在区块链技术方面的普及问题,或许我们不一定要完全教会大众理解区块链技术,当一些有行业痛点的企业开始用区块链技术去改善和颠覆他们自己的商业模式,用户不一定要理解一个项目区块链技术解决了什么问题,对用户来讲产品交互更友好,商品更优质,服务更上乘就可以了。未来,一个个基于区块链的产品和服务上线了,无声无息中大家都是区块链技术的用户、受益者了。就像不必懂互联网协议,我们都是互联网用户。后来我们迎来了区块链世界,我们都是区块链用户。


ERC875标准

https://github.com/ethereum/EIPs/issues/875

ERC875智能合约案例

https://github.com/alpha-wallet/ERC875-Example

项目采访

数字货币交易所何去何从?

用区块链技术实现影响力的商业价值

用区块链技术拉起股权交易市场新的增长曲线

基于智能合约和区块链技术的创新信贷交换平台

专家专栏

硅谷资深投资人讲析区块链项目投资|教程

王玮:区块链通证架构的思辨

软件好,才是真的好:区块链的1976—2017

信仰和投机:币圈没有奇迹

与元道对话三:区块链经济正在进行“动力切换”

百家观点

如何设计区块链项目的通证(token)模型

加密货币和区块链(一):历史的重演

裸照与区块链社群

疯狂的韩国比特币市场:“全民”炒币,人均收益率425%

开年反攻:泡沫中的token和被冷落的联盟链


对零识感兴趣的记者/活动/商务请甩Resume

至:hr@zkchainnews.cn

这篇关于首发|发币谁都会,你会发“货”么?是时候用Token干点“正经事”了的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/702574

相关文章

SpringBoot项目引入token设置方式

《SpringBoot项目引入token设置方式》本文详细介绍了JWT(JSONWebToken)的基本概念、结构、应用场景以及工作原理,通过动手实践,展示了如何在SpringBoot项目中实现JWT... 目录一. 先了解熟悉JWT(jsON Web Token)1. JSON Web Token是什么鬼

Caused by: android.view.WindowManager$BadTokenException: Unable to add window -- token android.os.B

一个bug日志 FATAL EXCEPTION: main03-25 14:24:07.724: E/AndroidRuntime(4135): java.lang.RuntimeException: Unable to start activity ComponentInfo{com.syyx.jingubang.ky/com.anguotech.android.activity.Init

【NodeJS】Unexpected token (109:0) 返回错误码500

刚开始报错是这样的: Unexpected token call 是什么我没看懂,但我发现 span.label.lable-success 后面的 #[i+1] 写错了,应该是 #{i+1} 改成完这个错误后又是一个错误提示: What? Unexpected token (109:0) 返回错误码500是什么鬼 我先将自己这段源码的 - if ... - else 检查下

解决OAuth Token,点击退出登录报404问题

首先,认证服务器发送请求 http://auth.test.com:8085/logout?redirect_uri=http://admin.test.com:8080’ 退出后报404无法跳转到网站首页,这个时候增加一个参数redirect_uri指定退出成功后跳转的路径,因为是自定义的,所以需在认证服务器做一些处理 找到源码默认实现接口DefaultLogoutPageGeneratingF

OAuth2 Token实现授权码模式

文章目录 OAuth2 授权:Resource owner password(密码模式)OAuth2 授权:Authorization code grant授权码模式,适用于浏览器模式OAuth2:Implicit(简化授权模式)OAuth:Client credentials(客户端证书)授权码模式使用案例 OAuth2 授权:Resource owner password(密

记一次knife4j文档请求异常 SyntaxError: Unexpected token ‘<‘, ... is not valid JSON

knife4j页面报错问题定位 前几天开发新接口,开发完成后想使用knife4j测试一下接口功能,突然发现访问页面报错提示:knife4j文档请求异常,但之前运行还是正常的,想想会不会与升级依赖有关系,启动其他微服务发现文档接口访问正常,排除因依赖版本升级导致在线API文档无法使用情况,还是和本服务新增接口有关系。 定位问题 首先f12打开调试台,重新刷新页面,看到console有报错提示

【Http 每日一问,访问服务端的鉴权Token放在header还是cookie更合适?】

结论先行: token静态的,不变的,放在header里面。 典型场景 ,每次访问时需要带个静态token请求服务端,向服务端表明是谁请求,此时token也可以认为是个固定的access-key。token动态的,会失效,放在cookie里面。 典型场景,业务登录态token,存在有效期的,过一段时间可能会失效。 下面具体展开下。 在选择将鉴权 Token 放在 HTTP Header 还是

JWT生成、解析token

目录 1. 导入JWT相关依赖2. JWT生成token3. JWT解析token4. 测试结果5. JWT加密、解密工具类 1. 导入JWT相关依赖 <!-- jwt认证模块--><dependency><groupId>io.jsonwebtoken</groupId><artifactId>jjwt-api</artifactId><version>0.10.2</

python eval报错 SyntaxError: invalid token

a = eval(startTime)   File "<string>", line 1     2019-01-02 11:00:00               ^ SyntaxError: invalid token startTime = '2019-01-02 11:00:00'a = eval(startTime) 具体内容如上: 后来发现,在eval中的

OpenFeign请求拦截器,注入配置属性类(@ConfigurationProperties),添加配置文件(yml)中的token到请求头

一、需求 OpenFeign请求拦截器,注入配置属性类(@ConfigurationProperties),添加配置文件(yml)中的token到请求头 在使用Spring Boot结合OpenFeign进行微服务间调用时,需要在发起HTTP请求时添加一些默认的请求头,比如认证令牌(token)。为了实现这一功能,可以创建一个请求拦截器,并且通过@ConfigurationPropert