Fountain上的赞与踩是一个非常有趣的设计。
从白皮书来看，在计算收益的时候，赞与踩的权重是相同的：
其中 是用户i的点赞与点踩次数的总和。
因此，无论一个用户对一篇文章是点赞还是点踩，贡献的热度值是完全相同的。
这样导致的结果，就是一篇一百人喜欢的文章，和一篇一百人唾骂的文章，将获得相同的收益。
更进一步，不好的文章如果有人还留言怼作者，而好文章如果大家就点赞而不留言，那很可能不好的文章的总热度反而更高，因为上述一篇文章的总热度是自身热度与子热度之和：
这就是说，一篇文章的子评论越多（二级甚至更深的孙评论不算），它从子评论上收到的热度贡献也就越多。
而，什么文章能吸引大家来广泛地留言评论呢？当然就是有争议的文章了。
所以，从收益规则上来看，有争议、或能引起广泛讨论的文章，是在Fountain上最容易获得高收益的文章。
当然，这只是从收益规则上来看。
由于收益规则是数据层的，在DAPP与APP的层面，情况会有所调整。
我们可以看到，即便赞和踩的作用是相同的，都起到了增加热度的作用，那么为什么Fountain不干脆直接取消赞和踩，只用热度这一个概念呢？
这里，有经验的产品应该就会想到，虽然在计算热度从而计算收益的时候赞和踩的作用一样，但分开的赞和踩在内容推送与呈现的角度还是可以存在差异的。
即，在表现层，赞和踩是有区别的，虽然在数据层两者可以认为没有分别。
举例而言，假如官方DAPP或APP从Fountain链上获取文章的数据后，将所有踩大于赞的文章都隐去，或者排序以一篇文章的总赞数减总踩数为排序权重做降序排列，那么用户通过官方DAPP或APP所看到的文章就会很不同，进而也就会影响到所有文章索取的热度。
由于用户不可能将所有文章都看一遍，因此文章的排序对文章上所获得的交互是有很大的影响的。
这里可选用的排序方式有很多，比如根据发布时间排序、根据总热度排序、根据赞踩的数量差排序、根据赞踩的权重差排序，或者是根据累计几天（比如三天或者一周）内的总热度、赞踩数量差或赞踩权重差的加权累计值排序，等等。
不同的排序方式便体现了社区对不同类型文章的偏好程度，而这一切都和链无关，所以我们在白皮书上暂时看不到具体方案。
这就牵扯到了白皮书上一个很有趣的细节。
从白皮书我们可以看到，Fountain链的目标并不仅仅是为简书做链改，它们的关系是合作关系而非等同或隶属关系。Fountain的目标，可以定位在“内容创作、发表与社交的行业链”这点上。
这个行业链可以分为这么几个层次（从白皮书中所提到的Alpha阶段、Beta阶段和正式运营阶段可以看出端倪）：
- 行业层
- 社区层
- 应用层
链本身可以看做是一个大型的分布式数据库，配上一套代币生态规则。
生态规则部分是否是行业级的我们先不管，从数据的角度来说，Fountain中的用户交互数据记在链上，这是区块链的标准做法。但这里就留下了一句潜台词：只要满足相关标准与协议，任何DAPP都可以读取这些数据（技术白皮书部分有提到准入机制，可见Fountain是欢迎大家开发自己的DAPP的）。
当然，从白皮书看来，Alpha阶段可能还不在链上，Beta阶段开始才在链上，因为Alpha阶段提到“将与合作方一同建立一套基于链上交互行为的收益核算系统”，而在Beta阶段提到“逐步将上一阶段中在云端完成的工作逐步转移到链上”，可见Alpha阶段很可能是在云端，到了Beta阶段才全部在链上。这个考虑到开发的渐进性其实很正常，也不算什么问题。
因此，我们可以想到，未来Fountain的应用生态很可能是这样的：
在一个官方DAPP的模范下，可以存在大量第三方DAPP，使用Fountain上的文章数据、用户数据和交互数据，打造自己的社区，只要符合相关规范。
因此，回到上面说的排序问题，不同的DAPP，无论是官方的还是第三方的，原则上都可以有自己的排序。举例来说，官方的DAPP假如以文章的赞踩权重差做排序，但我自己做的DAPP可以以文章的总热度来排序，你做的DAPP可以以时间排序，甚至于某人做的DAPP可以只显示自己与朋友所写的文章，另一个人做的DAPP则只显示与IT相关的文章，等等等等。
这是我认为Fountain链最有特色的部分——只要满足一定的准入条件，这个链上可以有大量定制化的社区DAPP，而不只局限在Fountain的官方DAPP，或者简书的Fountain DAPP上。
因此，Fountain的这种开放性在未来很可能会引领一波内容DAPP的出现。
再往开放的角度考虑，结合合作伙伴扩展方向中所提到的IP孵化的概念，既然每个用户都可以为自己的写作计划创立独立的Token池，那也就是说，至少从技术角度来说，不同的DAPP基于Fountain链的数据开设自己的社区代币，设置自己的社区代币经济生态，也不是绝对不可能。
当然，这部分想得略微有点狂野了，要看未来Fountain的发展如何，但想想还是有点小期待的。
回到收益的问题上。
在之前的文章中提到，不考虑尾部抑制与子评论热度叠加的情况下，每个用户只要交互了，那么收益就是固定的，正比于自己的可用FP量（总FP量扣除准备金）。比如我的可用FP量是你的三倍，我们都交互了，那么我通过交互获得的FP奖励就是你所得到的奖励的三倍。
在考虑上尾部抑制的情况下，只要不是看到低热度且预期也不会有高热度增长空间的文章就点赞/踩，那么对普通用户来说影响不大。
真正会发生改变的是子评论的热度叠加，让我们来举个例子（下面都认为所有交互都发生在尾部抑制区之外）。
总共有100篇文章，现在的总热度为H。然后有一篇内容，当前热度是h，一个用户进行第一次操作，他的可用FP量为F，那么为这篇内容的热度带来的增幅就是。如果这篇内容是一篇文章，那么对总热度的提升就是
；而如果这篇内容是一篇评论，那么这次点赞/踩还会影响到这篇评论的上一级内容（文章或者评论），为它带来热度增益：
，从而总热度增幅为
。
现在来看这位用户自身的收益。当是对文章进行点赞时，收益为：
而当是对评论进行点赞时，收益为：
这里是内容的自身热度，
是内容的子评论热度。
因此，当只进行一次交互的时候，在不考虑内容的自身热度与子评论热度的情况下，对文章进行点赞/踩的收益要比对评论进行赞/踩的收益大。
但，如果不是第一次交互，那情况就不一样了。
情况还是上面的情况。用户此前已经进行了C次交互，其中给文章交互了次，给评论交互了
次，其总收益应该是：
求和对所有内容进行，其中表示在内容i上的交互次数，即有交互为1，没有交互为0。
是内容i的自身热度，
是内容i的子评论热度，
是内容的热度分布比，可以记为
。
社区总热度可以分解为：
是给所有文章的交互总热度，
是给所有评论的交互总热度，两者的合为所有用户的交互总权重，从等于所有参与交互的用户总可用FP总量：
。
当用户为文章点赞时，总热度会下降为：
而当用户为评论点赞时，总热度则为上升为：
因此，直觉认为是当用户为文章点赞时因为总热度下降，所以获得的收益更多，而为评论点赞时总热度上升，所以收益减少。
但由于需要对分布总热度求和，所以情况实际上比这个要复杂得多。我们下面就来考虑这个总热度分布比。
由于无论是为文章还是评论点赞，被点赞的内容总是新的，所以都会增加一项。与此同时，所有参与交互的内容本身，由于交互权重从
下降为
，从而很可能会有所上升——但如果该内容的子评论曾被点过赞，那么情况就会很不一样：
这里是内容i的子评论中被点赞过的子评论的数量。当点赞子评论数满足
时，我们有
。
而如果新点赞的内容正好是某一个已点赞过的内容的子评论，那么这个已点赞过的内容的热度分布比的变化就更有趣了：
此时若点赞子评论数满足，则
。
由此可见，如果要收益尽可能地增大，那么最好的方法就是为自己点赞过的内容的子评论点赞，且需尽量选择热度分布比大且点赞子评论数少的内容点赞。
当点赞数量已经很大时，我们可以近似计算：
我们取，代表给评论点赞和给文章点赞的一个权重因子，而用
代表点赞前后每个赞的权重差，那么点赞后的总热度可以写为
。
同时，我们记为新点赞内容点赞后的热度分布比，从而点赞后要获得更高收益，就要求下面这个不等式成立：
我们可以进一步做近似，对文章的总热度和自身热度做平均处理，便有，即所有内容的自身热度除以总内容数，而
，即所有内容的总热度除以总内容数。点赞子评论数则平均化为
，其中
为一个常数因子。最后，因为最多只有一篇内容的子评论被成为新点赞的目标，从而有
，其中
也是一个常数因子。
最后，我们用为用户的总热度分布比，因此要获得更多的收益，就要求下面这个近似条件下的不等式成立：
由此可见，最主要的就是新点赞内容点赞后的热度分布比，其次给已点赞过的内容的子评论点赞是很重要的，再来就是给文章点赞。
因此，收益最优化的方案也就呼之欲出了：
- 选择能引起评论的好内容（热度分布比大），文章优先；
- 为上述好内容点赞；
- 为自己点过赞的内容的子评论点赞。
