Gnoland被大众熟知首先是从一项Cosmos Hub上的提案引起的， 即 69号提案。

69号提案简单说， 就是CosmWasm智能合约希望集成到Cosmos Hub， 这个实际上是被不少人支持的， 理由也很充分， 给Cosmos Hub赋予更高的能力， 带来更多的使用场景， 最终也能为ATOM带来价值捕获。

Cosmos生态的创始人Jae Kwon第一个强烈反对， 甚至警告如果Cosmos生态通过了69提案他将建议社区 分叉Cosmos Hub，可见反对的激烈程度。

有人批评Jae， 认为他是为了自己的项目也是智能合约的定位， 所以强烈反对CosmWasm部署到Cosmos Hub。不过这一点有点立不住脚， 因为Jae对CosmWasm的评价早在几年前就有明确的说明， 参考 The Shape of Cosmos#smart-contracts[1]

Jae的理由是， Cosmos Hub应当遵循一个原则， 即Hub最小化， 即作为Cosmos Hub不应该有太多扩展的功能， 而是将扩展的能力放到其他的zone去完成， 这也符合去中心化的理念；同时， 更重要的一点是， 集成新的功能， 会带来 安全隐患。而CosmWasm最大的问题是还没有经历时间的考验， 在没有发展成熟之前总会经历恶意攻击的问题， 这将对Cosmos Hub形成致命的威胁。

这个担忧也并非空穴来分， 在之前Juno网络就因为CosmWasm问题出现停机的情况， 所以Jae反对CosmWasm集成在Cosmos Hub。

当然， Jae是大棒与胡萝卜并举， 在反对的同时也明确， 凡是反对69号提案的将有机会获得Gnoland项目的 空投。

如他所愿， 最终69号提案被否决。

从某个角度说可以认为CosmWasm和Gnoland也是一个并列或者竞争的关系， 即CosmWasm和GnoVM层面。

回到Why Gnoland这个问题， 答案是， Jae认为现有的基于Cosmos SDK来开发应用链的难度还是偏大， 从0到1开发需要兼顾很多的方面， 比如网络安全， 治理等等。而Gnoland就是为了 降低开发门槛。

Gnoland的降低开发门槛一个是将应用链的开发转为智能合约的开发；另一个是开发工具上选择Gnolang这个基于Go这样一门更广泛使用的被Google支持的语言。

如果说降低开发门槛角度， 和Gnoland有类似定位的其实还挺多的， 除了基于智能合约的类似Juno这样的项目， 还有 Evmos也是着力于降低开发门槛以及寻找更多的开发者支持。 这一点来说， Gnoland还是有自己的挑战需要面对的。

3/ Gnoland背后的组织

Gnoland背后的组织变化目前还是挺大的， 牵扯到Jae Kwon以及Ignite。

最早peng zong在的时候， Ignite从NewTendermint独立开。

最新情况是Ignite分为4个实体：

1、AiB作为母公司， 共享相关资源给其他实体

2、原先的Ignite专注在Ignite CLI工具端的开发（Ignite CLI原先是starport）， 另外Ignite 加速器也在Ignite名下。

3、 NewTendermint负责开发 Tendermint2.0和Gnoland以及Cosmos SDK。这里需要注意一下的是Tendermint2.0其实可以理解为原来Tendermint的一个分支， 具体名字是Tendermint Classic， 我看到github上的代码是2年前就有了。Jae的想法应该是对原来的做一些简化， 不过简化之后两者之间的兼容性如何目前没有公开资料。

4、新成立的一个实体是Anamika， 负责开发Cosmos Cash， 这是一个和合规相关的内容， 是一个Cosmos SDK模块。

官方解释这次变化主要是熊市大背景下的一个例行收缩，以及将重点瞄准重点内容，提升效率。

Gnoland被大众熟知首先是从一项Cosmos Hub上的提案引起的， 即 69号提案。

69号提案简单说， 就是CosmWasm智能合约希望集成到Cosmos Hub， 这个实际上是被不少人支持的， 理由也很充分， 给Cosmos Hub赋予更高的能力， 带来更多的使用场景， 最终也能为ATOM带来价值捕获。

Cosmos生态的创始人Jae Kwon第一个强烈反对， 甚至警告如果Cosmos生态通过了69提案他将建议社区 分叉Cosmos Hub，可见反对的激烈程度。

有人批评Jae， 认为他是为了自己的项目也是智能合约的定位， 所以强烈反对CosmWasm部署到Cosmos Hub。不过这一点有点立不住脚， 因为Jae对CosmWasm的评价早在几年前就有明确的说明， 参考 The Shape of Cosmos#smart-contracts[1]

Jae的理由是， Cosmos Hub应当遵循一个原则， 即Hub最小化， 即作为Cosmos Hub不应该有太多扩展的功能， 而是将扩展的能力放到其他的zone去完成， 这也符合去中心化的理念；同时， 更重要的一点是， 集成新的功能， 会带来 安全隐患。而CosmWasm最大的问题是还没有经历时间的考验， 在没有发展成熟之前总会经历恶意攻击的问题， 这将对Cosmos Hub形成致命的威胁。

这个担忧也并非空穴来分， 在之前Juno网络就因为CosmWasm问题出现停机的情况， 所以Jae反对CosmWasm集成在Cosmos Hub。

当然， Jae是大棒与胡萝卜并举， 在反对的同时也明确， 凡是反对69号提案的将有机会获得Gnoland项目的 空投。

如他所愿， 最终69号提案被否决。

从某个角度说可以认为CosmWasm和Gnoland也是一个并列或者竞争的关系， 即CosmWasm和GnoVM层面。

回到Why Gnoland这个问题， 答案是， Jae认为现有的基于Cosmos SDK来开发应用链的难度还是偏大， 从0到1开发需要兼顾很多的方面， 比如网络安全， 治理等等。而Gnoland就是为了 降低开发门槛。

Gnoland的降低开发门槛一个是将应用链的开发转为智能合约的开发；另一个是开发工具上选择Gnolang这个基于Go这样一门更广泛使用的被Google支持的语言。

如果说降低开发门槛角度， 和Gnoland有类似定位的其实还挺多的， 除了基于智能合约的类似Juno这样的项目， 还有 Evmos也是着力于降低开发门槛以及寻找更多的开发者支持。 这一点来说， Gnoland还是有自己的挑战需要面对的。

3/ Gnoland背后的组织

Gnoland背后的组织变化目前还是挺大的， 牵扯到Jae Kwon以及Ignite。

最早peng zong在的时候， Ignite从NewTendermint独立开。

最新情况是Ignite分为4个实体：

1、AiB作为母公司， 共享相关资源给其他实体

2、原先的Ignite专注在Ignite CLI工具端的开发（Ignite CLI原先是starport）， 另外Ignite 加速器也在Ignite名下。

3、 NewTendermint负责开发 Tendermint2.0和Gnoland以及Cosmos SDK。这里需要注意一下的是Tendermint2.0其实可以理解为原来Tendermint的一个分支， 具体名字是Tendermint Classic， 我看到github上的代码是2年前就有了。Jae的想法应该是对原来的做一些简化， 不过简化之后两者之间的兼容性如何目前没有公开资料。

4、新成立的一个实体是Anamika， 负责开发Cosmos Cash， 这是一个和合规相关的内容， 是一个Cosmos SDK模块。

官方解释这次变化主要是熊市大背景下的一个例行收缩，以及将重点瞄准重点内容，提升效率。