经过研究感觉NKN的设计整体上是很有创新的，但是客户端的隐私性事实上是无法得到保障的，只要知道了客户端的公钥，任何人都可以通过getwsaddr rpc调用来获取客户端连接到的节点地址…这么一来无论中间有多少节点转发，对客户端的隐私保护都无济于事。不知道是不是我的理解有误？
1 Like
不是这样的。我这里讨论两个方面的隐私。
最重要的隐私是通讯内容的隐私。这个可以完全保证的原因是，所有的通讯都是端到端加密的，也就是说，如果你只知道公钥而不知道私钥，是无法解密发个这个公钥的消息的，也无法以这个公钥的身份和别人发送消息，简单来说就是什么都做不了，除非你拥有对应的私钥。
上面说的是通讯内容的隐私。如果你讨论的是客户端连接到的节点的隐私的话，那么有两个相关的因素。一个是，客户端可以通过选择 identifier 来切换连接到的节点。另一个是，即使你知道一个客户端连接到的节点，只要你不是这个节点的运行者，那你也是获取不了额外的信息的。
这个是可以的，计算量对于大部分设备来说并不是很大，因为只涉及到哈希的计算，应该在毫秒级的时间里面就可以算出来
你说的应该是这个函数 https://github.com/nknorg/nkn/blob/master/lnode/localnode.go#L298
这里调用的是 nnet 里面 Chord 的 FindPredecessors 方法，即寻找 Chord 环上某个地址之前的节点地址。不过如果你需要在 client 侧按照你说的方法计算的话，是不需要每次都调用这个函数的。只需要调用一次目标节点的 RPC 请求，获取其 successor，然后在内存中计算即可，保证 client 的环上位置在目标节点和他的 successor 之间即可。这样一共只需要一次网络请求。
对不起，暂时没能理解你的意思。getwsaddr只能获取Predecessors的IP地址和pubkey。然后我查了文档，没有找到能获取successor的RPC调用，之前思路是先调用 getneighbor，如果现在能有直接获取successor的RPC调用就太好了。
successor 的信息（以及其他 Chord 相关的信息）可以用这个 RPC 获得：getchordringinfo
我也在想解决这个问题，但我现在工程方面遇到了一些问题。主要是以下几点：
1是ID生成的算法不清楚：按照文档描述是sha1，但我尝试hashlib.sha1(“1.1.1.1:30001”.encode(‘utf-8’))这样计算的结果和官方rpc算出来的ID不一致；2是getchordringinfo会得到一系列successor ，按文档描述第一个successor 就是离节点最近的吧，只要确保client的ID落到这里面就行了。还希望yilun能指点下。
我已经实现了，你这个client的地址生成不对。client的地址是hash256(iden.pubkey),其他参考nnet中的compareID和distince
请问你看的是哪里的文档呀？我们从来没有用过 sha1。协议的描述在这里 https://docs.nkn.org/docs/client-address-scheme
注意，这里的 ID 仅限于 client 的 ID，node 的 ID 比较复杂，不过和你要做的功能应该是没有关系的。
感谢，已经解决了。另外就是，我想在nmobile中加入实时语音功能，你觉得现实不现实，会不会延迟非常的大
这个和两侧用户的网络关系很大。我这边的网络比较好，用 NKN multiclient 的端到端延迟一般也就是一百多毫秒，用来语音的话没问题。但是一些地方的网络会有好几百毫秒的端到端延迟，用来语音的话可能就会有比较显著的延迟了。
此外，如果想要实现效果比较好的语音功能，是不能用和 TCP 兼容的 session 模式的，而是需要把 multiclient 发送的包当做 UDP 的数据包，在客户端自行编解码。
总的来说的话，我估计在网络好的地区效果会很好，但是在网络比较慢的地区，效果可能比较差。
另一个选择是使用 nkn-tuna-session 来做付费的端到端连接。由于这里只有一跳中转，延迟会低很多，大部分时候几乎和直连相当，代价就是需要给中转节点支付少量的 token 作为中转的流量开销。不过由于语音的数据量很小，支付的 token 价格是极低的，按照目前的价格，如果编解码处理得当的话，一小时的语音也就一分多钱等值的 token，基本上可以忽略不计。nkn-tuna-session 的 UDP 功能目前正在开发中，这两周应该就可以用了。
看来大部分人对nmobile的功能不太满意 
我一直在想一点，multiclient对与客户端而言，是不是接入网络的第一个节点还是固定的，但后面的链路会分叉呢？而nkn-tuna-session强制只有一跳中转，是不是节点的选择就不是根据chord dht了，而是直接连接对面client接入网络的节点了（就是我用getwsaddr就可以知道两面连接的中转节点地址了）
包括第一个节点在内的全部节点，其实都是有可能动态变化的。tuna-session 的节点选择和 Chord DHT 完全无关，甚至都和 NKN Node 无关，而是 listen 端在运行 tuna 的公共节点里面选择和自己连接速度快的，数据也不经过 NKN client，和 Client 那一套是完全独立的。
所以说multiclient和tuna-session都和chord dht无关了，基本纯随机分配。这样难免让使用者感觉到不可靠
不过根据tuna文档，我只要搭建一个tuna-exit server就可以保障安全了。tuna-exit server与tuna entry进行交互，客户端后面就相当于一个localserver，只负责收信息就可以
这个完全反了。正是因为和 Chord DHT 无关，节点的分配才能基于 IP 和性能。依赖 Chord DHT 分配的反而是接近随机分配。
hash256(identifier.pubkey)生成的id，切换identifier计算出来结果也是不可控的，如何保证环上位置能落在目标节点和他的successor之间？
可以通过尝试不同的 identifier 来穷举
NKN Tuna Session需要smux 2.0.1，但smux github上的最新版本是1.5.15，这导致go编译无法通过。。。。。
你的 Go 版本是多少？