Closed nebali closed 5 years ago
OmiseGO AMA 12 - 2019年1月18日
你们在法币入口的层面的合作进展如何了？是否有部分入口已经被锁定？
有关法币入/出的工作仍在推进，这其中包含了广泛的渠道--从OmiseGO自己的支付网关，为到 eWallet 用户而建立的银行合作关系，再到允许用户直接通过加密货币来购买实物商品或服务的去中心化应用 (dApp)。
我们现在没有任何合作伙伴关系可以拿来作为谈资。事实上，只有项目进入了测试网阶段，创建了包含完整技术堆栈的工作原型后，这些合作关系才能巩固。
在目睹了社区里面的积极言论和消极言论之后，您希望我们深入理解哪些理念或者概念？
首先我们需要明白的是，去中心化并不是空穴来风或者昙花一现的噱头；它在我们的商业模式中处于核心地位，并且是实现商业模式按预期正常运转的唯一路径。尽管人们对这个词感到视觉疲劳，但我们会一如既往的坚持去中心化这个原则。去中心化是我们项目不可或缺的一部分，如果我们避之不谈，甚至不去尝试，那么这一定不是个正确选择。
引用曾经的AMA中的一句话：
去中心化是一种渗透到技术、经济体系和机制设计等诸多领域的意识形态。我们在设计SDK、Plasma、去中心化交易所(DEX)以及我们通过以太坊社区基金协助的一些项目的UX(用户体验)时，秉承的就是去中心化的思想。
我们何时能看到2019/2020年度的路线图更新？
当前和未来的项目发展里程碑事件详见： https://blog.omisego.network/state-of-the-omg-ecosystem-75260c71a053
我们不会继续做的事情: https://www.reddit.com/r/omise_go/comments/9wi6ed/daily_discussion_november_13_2018/e9moe9x/?context=3。
至于2019年具体的路线图，我们有具体的时间规划，但是我们不会对外公开。预了解我们项目一步一步的发展历程，点击链接，追踪我们的动向。
如果交易成本并不高，系统的处理能力仅有125TPF，那么有什么低成本且高效的方法能够阻止别有用心的人涌入网络中使网络崩溃呢？换言之，假如某个不受 OmiseGO 管控的app或者游戏每10秒就会将其用户连接至网络，因为在OMG网络中，同时连接1250个用户就能在OMG网络中创造出125TPS，那会怎样呢？我可以不知道你们如何处理这个问题，当想知道你们是否正在应对这一问题。
是的，我们意识到了这个问题并在积极处理。我们主要努力方向是提高网络容量，使其能够应对任何突发情况。
目前也有潜在的解决方案。例如限流或者排队，如果发生了DDOS攻击或者功能上出现了类似问题，即不良的程序设计导致了网络中出现大量无法处理的交易，可以通过限流或者排队的方式应对--虽然我们当前还没有使用这些措施，但值得一提的是，这种方案解决问题的可能性是存在的。
注：一个app每10秒连接一次用户，不等于这个app每10秒为用户创造一次交易。如果一个app每10秒为每个用户创造一次交易，无论单个交易成本有多低，最后交易都会贵得离谱（这也是我们之所以在上文提到不良的程序设计的原因）。但实际情况是，尽管这确实是件很荒谬的事情，但并不意味着没人去做，因此我们会将这种情况纳入考虑范围。
在进行MVP设计过程中，你们遇到的最大的挑战是什么？
一些颇具难度的挑战在从 MVP 到 MoreVP 的转换过程产生了，我们认为 MoreVP 是最佳的设计方案（不像MVP，需要通过大量的用户交互才能执行基本操作）。
MoreVP 是一个具有多个步骤的交互协议，比 MVP 复杂得多。展望未来，我们将把 MoreVP 作为我们的首个外部测试网进行发布，因此考虑所有的极端案例已经是一项重大的人物。
Final version
nebali
commented
5 years ago nebali
commented
5 years ago
OmiseGO AMA 12
OmiseGO AMA 12 - 2019年1月18日
你们在法币入口的层面的合作进展如何了？是否有部分入口已经被锁定？
有关法币入/出的工作仍在推进，这其中包含了广泛的渠道--从OmiseGO自己的支付网关，为到 eWallet 用户而建立的银行合作关系，再到允许用户直接通过加密货币来购买实物商品或服务的去中心化应用 (dApp)。
我们现在没有任何合作伙伴关系可以拿来作为谈资。事实上，只有项目进入了测试网阶段，创建了包含完整技术堆栈的工作原型后，这些合作关系才能巩固。
在目睹了社区里面的积极言论和消极言论之后，您希望我们深入理解哪些理念或者概念？
首先我们需要明白的是，去中心化并不是空穴来风或者昙花一现的噱头；它在我们的商业模式中处于核心地位，并且是实现商业模式按预期正常运转的唯一路径。尽管人们对这个词感到视觉疲劳，但我们会一如既往的坚持去中心化这个原则。去中心化是我们项目不可或缺的一部分，如果我们避之不谈，甚至不去尝试，那么这一定不是个正确选择。
引用曾经的AMA中的一句话：
我们何时能看到2019/2020年度的路线图更新？
当前和未来的项目发展里程碑事件详见： https://blog.omisego.network/state-of-the-omg-ecosystem-75260c71a053
我们不会继续做的事情: https://www.reddit.com/r/omise_go/comments/9wi6ed/daily_discussion_november_13_2018/e9moe9x/?context=3。
至于2019年具体的路线图，我们有具体的时间规划，但是我们不会对外公开。预了解我们项目一步一步的发展历程，点击链接，追踪我们的动向。
如果交易成本并不高，系统的处理能力仅有125TPF，那么有什么低成本且高效的方法能够阻止别有用心的人涌入网络中使网络崩溃呢？换言之，假如某个不受 OmiseGO 管控的app或者游戏每10秒就会将其用户连接至网络，因为在OMG网络中，同时连接1250个用户就能在OMG网络中创造出125TPS，那会怎样呢？我可以不知道你们如何处理这个问题，当想知道你们是否正在应对这一问题。
是的，我们意识到了这个问题并在积极处理。我们主要努力方向是提高网络容量，使其能够应对任何突发情况。
目前也有潜在的解决方案。例如限流或者排队，如果发生了DDOS攻击或者功能上出现了类似问题，即不良的程序设计导致了网络中出现大量无法处理的交易，可以通过限流或者排队的方式应对--虽然我们当前还没有使用这些措施，但值得一提的是，这种方案解决问题的可能性是存在的。
注：一个app每10秒连接一次用户，不等于这个app每10秒为用户创造一次交易。如果一个app每10秒为每个用户创造一次交易，无论单个交易成本有多低，最后交易都会贵得离谱（这也是我们之所以在上文提到不良的程序设计的原因）。但实际情况是，尽管这确实是件很荒谬的事情，但并不意味着没人去做，因此我们会将这种情况纳入考虑范围。
在进行MVP设计过程中，你们遇到的最大的挑战是什么？
一些颇具难度的挑战在从 MVP 到 MoreVP 的转换过程产生了，我们认为 MoreVP 是最佳的设计方案（不像MVP，需要通过大量的用户交互才能执行基本操作）。
MoreVP 是一个具有多个步骤的交互协议，比 MVP 复杂得多。展望未来，我们将把 MoreVP 作为我们的首个外部测试网进行发布，因此考虑所有的极端案例已经是一项重大的人物。