如何设计一个去中心化的织网
织网，大家都知道，最近也是频上热搜，今天我们不去聊织网，我们来聊一下如何设计一个去中心化的织网。本文难免有考虑不全面的地方，欢迎留言讨论。 在这里，我们要解决的问题包括：如何让论文作者的劳动成果不被白嫖如何确保这个多边市场（作者、读者等）能够持续运行下去解决方案通过在以太坊等公链平台上，搭建一个去中心化的平台，作者在平台上发布论文的时候，mint 出该论文的 NFT。为了确保作者上传的是真的论文，而不是随意的文档文件，可以引入审校机制，即必须有多位其他的作者投票，该论文的 NFT 才能被成功 mint，通过作者的 address，可以看到 ta 所有的 NFT，即成功发表的论文清单。论文原件存储在 IPFS、Arweave 等去中心化存储上。 读者阅读论文，则需要支付 token。该 token 的获取有多种渠道，包括现金购买、在社区内做贡献获得、他人赠与等方式。支付上来的 token，一部分用于智能合约损耗、一部分用于给到作者本人。所有持有 token 的用户，都可以参与社区内的事务投票。 关于论文定价问题，每篇论文的价格应该是不同的，作者设置一个初始价格，如果该论文被其他论文...
如何设计一个去中心化的织网
织网，大家都知道，最近也是频上热搜，今天我们不去聊织网，我们来聊一下如何设计一个去中心化的织网。本文难免有考虑不全面的地方，欢迎留言讨论。 在这里，我们要解决的问题包括：如何让论文作者的劳动成果不被白嫖如何确保这个多边市场（作者、读者等）能够持续运行下去解决方案通过在以太坊等公链平台上，搭建一个去中心化的平台，作者在平台上发布论文的时候，mint 出该论文的 NFT。为了确保作者上传的是真的论文，而不是随意的文档文件，可以引入审校机制，即必须有多位其他的作者投票，该论文的 NFT 才能被成功 mint，通过作者的 address，可以看到 ta 所有的 NFT，即成功发表的论文清单。论文原件存储在 IPFS、Arweave 等去中心化存储上。 读者阅读论文，则需要支付 token。该 token 的获取有多种渠道，包括现金购买、在社区内做贡献获得、他人赠与等方式。支付上来的 token，一部分用于智能合约损耗、一部分用于给到作者本人。所有持有 token 的用户，都可以参与社区内的事务投票。 关于论文定价问题，每篇论文的价格应该是不同的，作者设置一个初始价格，如果该论文被其他论文...
NFT 白名单实现方案
白名单现在已经成为 NFT 项目必备运营方式了，因为 NFT 数量有限，一般就是 1 万个，通过白名单可以刺激社区成员的参与度，比如社群里回答问题、在社交平台上帮助项目方推广、拉新用户等。项目一开始也只会开放给白名单来 mint，然后由这些用户上交易所进行二级市场交易。 本文将介绍下如何在智能合约里实现白名单，除了 NFT 项目，其他需要白名单的项目都可以采用这样的方案。设计思路也很简单，就是使用一个 mapping 来保存用户地址即可，把添加和移除白名单的权限开放给管理员。为什么不使用数组呢，是因为如果是数组实现，那么在验证某个用户是否在白名单里，就需要遍历数组才行，这会增加资源的消耗，即导致 gas 费用比较高。 以下为代码和对应的注释：// SPDX-License-Identifier: GPL-3.0 pragma solidity >=0.8.0 <0.9.0; contract Whitelist { mapping(address => bool) whitelists; address owner; constructor() { owner = ms...
NFT 白名单实现方案
白名单现在已经成为 NFT 项目必备运营方式了，因为 NFT 数量有限，一般就是 1 万个，通过白名单可以刺激社区成员的参与度，比如社群里回答问题、在社交平台上帮助项目方推广、拉新用户等。项目一开始也只会开放给白名单来 mint，然后由这些用户上交易所进行二级市场交易。 本文将介绍下如何在智能合约里实现白名单，除了 NFT 项目，其他需要白名单的项目都可以采用这样的方案。设计思路也很简单，就是使用一个 mapping 来保存用户地址即可，把添加和移除白名单的权限开放给管理员。为什么不使用数组呢，是因为如果是数组实现，那么在验证某个用户是否在白名单里，就需要遍历数组才行，这会增加资源的消耗，即导致 gas 费用比较高。 以下为代码和对应的注释：// SPDX-License-Identifier: GPL-3.0 pragma solidity >=0.8.0 <0.9.0; contract Whitelist { mapping(address => bool) whitelists; address owner; constructor() { owner = ms...
从机会中找问题，还是从问题中找机会
最近和别人探讨一个技术的落地场景，由此带来一些思考。 首先，对于一个产品，并不是要能解决所有的问题，它才能是一个好产品，而是只要能要解决一个核心问题，它就是一个好产品。产品的好坏不在于产品本身属性来决定的，而是在于它对于需求的解决。用户愿意使用你的产品，不在于你的产品做的有多好、技术有多强大、界面有多漂亮，而在于这个产品可以解决自己的问题。从接触、到使用、到习惯、到离不开，一定是因为问题很痛，而产品解决了痛点。 但是一个产品并不一定能够解决所有的问题。比如日常的商业往来，可以通过合同约束，这是一个解决办法。但是即使有法律的约束，依然是会出现违约的，但不能得到结论说，合同不能解决问题，从而否定了合同的作用。 只要这个产品能够在某个关键需求上，带来超过当前解决方案的体验和替换成本，那这个产品就具有市场。虽然交易的达成，并非单产品的功劳，还有销售等的作用，但是产品一定是第一位的。 其次，不能因为有问题就否定，有问题反而是好事儿，因为这里面有需求、有痛点。否定一个想法、找出一个问题，是容易的，也是懒惰的。我们更应该从问题中看到需求，进而去寻找解决方案来满足需求，而非仅仅停留在否定上。每一...
从机会中找问题，还是从问题中找机会
最近和别人探讨一个技术的落地场景，由此带来一些思考。 首先，对于一个产品，并不是要能解决所有的问题，它才能是一个好产品，而是只要能要解决一个核心问题，它就是一个好产品。产品的好坏不在于产品本身属性来决定的，而是在于它对于需求的解决。用户愿意使用你的产品，不在于你的产品做的有多好、技术有多强大、界面有多漂亮，而在于这个产品可以解决自己的问题。从接触、到使用、到习惯、到离不开，一定是因为问题很痛，而产品解决了痛点。 但是一个产品并不一定能够解决所有的问题。比如日常的商业往来，可以通过合同约束，这是一个解决办法。但是即使有法律的约束，依然是会出现违约的，但不能得到结论说，合同不能解决问题，从而否定了合同的作用。 只要这个产品能够在某个关键需求上，带来超过当前解决方案的体验和替换成本，那这个产品就具有市场。虽然交易的达成，并非单产品的功劳，还有销售等的作用，但是产品一定是第一位的。 其次，不能因为有问题就否定，有问题反而是好事儿，因为这里面有需求、有痛点。否定一个想法、找出一个问题，是容易的，也是懒惰的。我们更应该从问题中看到需求，进而去寻找解决方案来满足需求，而非仅仅停留在否定上。每一...
关于产品设计的思考
在日常中，我们总是会听到诸如“我的产品比 XX 好多了，凭什么它卖的比我的好？”、“我的产品技术含量很高的，是用户不识货？”等等。本篇文章分享一些我在产品方面的思考。本文仅关注产品设计本身，并没有涉及到销售和营销的讨论。 首先，产品卖的好不好，与产品本身技术含量的高低并无关系，甚至有些时候和产品本身的质量都没有关系，产品是为了需求而设计的，最重要的是它得能满足需求，这个需求往往具有情景的约束。 产品不是为人设计的，产品是为一系列的需求的集合而设计的。我想这也是为什么在敏捷开发里要引入故事板这个概念，我们在设计产品的时候，脑海里是有用户在具体情景下使用本产品解决问题这个清晰的画面的。 所以产品的设计不能是凭空想象的，是需要从用户那里去挖掘的。有时候，用户说的并不一定真的是核心需求，这就需要识别能力了。我们往往会犯的问题是拿着锤子看什么都是钉子。 其次，产品的价值要大。用户为什么要用你的产品，一定是产出大于投入。用户使用产品是需要付出成本的，即使是免费的产品。付出的可以是金钱、可以是时间、可以是社交关系等等。 这里的价值并不是单指我们的产品本身价值要大，价值 = 新体验 - 旧体验 ...
关于产品设计的思考
在日常中，我们总是会听到诸如“我的产品比 XX 好多了，凭什么它卖的比我的好？”、“我的产品技术含量很高的，是用户不识货？”等等。本篇文章分享一些我在产品方面的思考。本文仅关注产品设计本身，并没有涉及到销售和营销的讨论。 首先，产品卖的好不好，与产品本身技术含量的高低并无关系，甚至有些时候和产品本身的质量都没有关系，产品是为了需求而设计的，最重要的是它得能满足需求，这个需求往往具有情景的约束。 产品不是为人设计的，产品是为一系列的需求的集合而设计的。我想这也是为什么在敏捷开发里要引入故事板这个概念，我们在设计产品的时候，脑海里是有用户在具体情景下使用本产品解决问题这个清晰的画面的。 所以产品的设计不能是凭空想象的，是需要从用户那里去挖掘的。有时候，用户说的并不一定真的是核心需求，这就需要识别能力了。我们往往会犯的问题是拿着锤子看什么都是钉子。 其次，产品的价值要大。用户为什么要用你的产品，一定是产出大于投入。用户使用产品是需要付出成本的，即使是免费的产品。付出的可以是金钱、可以是时间、可以是社交关系等等。 这里的价值并不是单指我们的产品本身价值要大，价值 = 新体验 - 旧体验 ...
敏捷、精益与不确定性
敏捷是一个思想或原则，最早是用在软件项目管理上，现在很多非软件项目也是使用敏捷的思想来确保成功率。精益是精益创业，是一个用在创业上的方法论，创业成功概率低，通过精益的思想，可以降低成本、提高成功率。这二者名字虽然不同，方法上也有区别，但是其底层的逻辑我认为是一致的，都是很好的应对不确定性的方法。 在软件开发的项目管理中，为了降低失败率，一种办法是做详细的完整计划，把每个环节都考虑到，一个流程接着一个流程，就像瀑布一样，从上流到下，这种模式也被成为瀑布模式。但是这种方法失败率是很高的，计划做完的那一刻，就是计划已经过时了。这在很多行业里都是一样的，因为现实世界是动态的，计划就是对未来的预测。但是这并不是说不要做计划，这会走向另一个极端了。 而敏捷的思想就可以很好的解决这个问题，敏捷是拥抱变化的。它的方法就是，筛选出在一个很短的周期内（一般为 1 周到 3 周左右）能够完成的核心需求，在该周期内完成它。完成的标准是发布的这个产品用户可以直接使用，它可以功能少，但是要完整，而不是一个无法正常使用的残次品。完成之后，团队应该坐在一起进行反思，寻找本轮中哪些做的不好，应该如何改进，并找出一...
敏捷、精益与不确定性
敏捷是一个思想或原则，最早是用在软件项目管理上，现在很多非软件项目也是使用敏捷的思想来确保成功率。精益是精益创业，是一个用在创业上的方法论，创业成功概率低，通过精益的思想，可以降低成本、提高成功率。这二者名字虽然不同，方法上也有区别，但是其底层的逻辑我认为是一致的，都是很好的应对不确定性的方法。 在软件开发的项目管理中，为了降低失败率，一种办法是做详细的完整计划，把每个环节都考虑到，一个流程接着一个流程，就像瀑布一样，从上流到下，这种模式也被成为瀑布模式。但是这种方法失败率是很高的，计划做完的那一刻，就是计划已经过时了。这在很多行业里都是一样的，因为现实世界是动态的，计划就是对未来的预测。但是这并不是说不要做计划，这会走向另一个极端了。 而敏捷的思想就可以很好的解决这个问题，敏捷是拥抱变化的。它的方法就是，筛选出在一个很短的周期内（一般为 1 周到 3 周左右）能够完成的核心需求，在该周期内完成它。完成的标准是发布的这个产品用户可以直接使用，它可以功能少，但是要完整，而不是一个无法正常使用的残次品。完成之后，团队应该坐在一起进行反思，寻找本轮中哪些做的不好，应该如何改进，并找出一...
