Binance Square
胖鸟
2.2k Publicaciones

胖鸟

不喜欢卷
146 Siguiendo
1.4K Seguidores
3.4K+ Me gusta
Publicaciones
·
--
Ver traducción
@OpenGradient 文档里最关键的一句话,其实不是“可验证 AI”,而是它承认传统区块链那套重执行机制在 AI 面前根本跑不动。 这句话很狠。因为区块链过去最自豪的东西,就是所有验证者都重新执行一遍,谁也别信谁。可到了 AI 推理这里,这套神圣原则突然变成了笑话。一个 70B 模型,让一百个验证者一起跑一遍,成本直接炸穿天花板。最后得到的可能还是同一个结果,只是用户替这场“去中心化仪式”付了几十倍账单。 所以 OpenGradient 选择把执行和验证拆开。推理节点跑模型,全节点只验 TEE 或 ZKML 证明。听起来很优雅,像是终于给 AI 找到上链姿势。但我越看越觉得,这里面真正被牺牲的,是区块链最原始的那种安全直觉:大家亲自算一遍。 以前的信任来自重复执行,现在的信任来自证明文件。以前验证者看的是结果怎么一步步算出来,现在只看一张证明够不够合法。效率确实上来了,但系统也从“亲眼复算”变成了“相信证明体系”。 这就是 OpenGradient 最核心的赌注。它不是单纯在做 AI 推理网络,而是在赌未来高成本计算都不需要被全网重跑。只要证明足够强,计算可以外包,验证可以压缩,信任可以从“重复劳动”变成“证据检查”。 问题也在这里。谁来保证这套证明体系永远不出问题?TEE 依赖硬件,ZKML 贵到离谱,Vanilla 又几乎没安全性。看似三条路,实际上每条路都把风险换了个地方摆着。 所以我觉得 OpenGradient 真正大胆的地方,不是让 AI 上链,而是它把区块链最贵的安全传统砍掉了。它卖的不是“所有人一起验证”,而是“相信少数人执行,再让证明替大家背书”。 如果这条路走通,$OPG 买到的是新计算范式;如果走不通,那它只是把重复计算的成本,换成了证明系统的信任债。 #opg $OPG
@OpenGradient 文档里最关键的一句话,其实不是“可验证 AI”,而是它承认传统区块链那套重执行机制在 AI 面前根本跑不动。

这句话很狠。因为区块链过去最自豪的东西,就是所有验证者都重新执行一遍,谁也别信谁。可到了 AI 推理这里,这套神圣原则突然变成了笑话。一个 70B 模型,让一百个验证者一起跑一遍,成本直接炸穿天花板。最后得到的可能还是同一个结果,只是用户替这场“去中心化仪式”付了几十倍账单。

所以 OpenGradient 选择把执行和验证拆开。推理节点跑模型,全节点只验 TEE 或 ZKML 证明。听起来很优雅,像是终于给 AI 找到上链姿势。但我越看越觉得,这里面真正被牺牲的,是区块链最原始的那种安全直觉:大家亲自算一遍。

以前的信任来自重复执行,现在的信任来自证明文件。以前验证者看的是结果怎么一步步算出来,现在只看一张证明够不够合法。效率确实上来了,但系统也从“亲眼复算”变成了“相信证明体系”。

这就是 OpenGradient 最核心的赌注。它不是单纯在做 AI 推理网络,而是在赌未来高成本计算都不需要被全网重跑。只要证明足够强,计算可以外包,验证可以压缩,信任可以从“重复劳动”变成“证据检查”。

问题也在这里。谁来保证这套证明体系永远不出问题?TEE 依赖硬件,ZKML 贵到离谱,Vanilla 又几乎没安全性。看似三条路,实际上每条路都把风险换了个地方摆着。

所以我觉得 OpenGradient 真正大胆的地方,不是让 AI 上链,而是它把区块链最贵的安全传统砍掉了。它卖的不是“所有人一起验证”,而是“相信少数人执行,再让证明替大家背书”。

如果这条路走通,$OPG 买到的是新计算范式;如果走不通,那它只是把重复计算的成本,换成了证明系统的信任债。
#opg $OPG
·
--
Ver traducción
@OpenGradient 文档里 Data Nodes 这一段看着挺干净:外部 API、数据库、价格源都进 TEE,节点运营商看不到、改不了,还能生成证明。读第一遍像是补上了 AI 推理最缺的那块拼图,读第二遍我就有点发凉——它证明的是数据路上没被偷换,不是数据源头没烂。 如果价格 API 本来就慢半拍,数据库本来就是旧账,X 上的舆情数据早被水军刷成垃圾,Data Node 会怎么做?它不会判断这东西脏不脏,它只会把这口脏饭端得很规范:TEE 里取、签名、出证明、送给模型。最后链上留下的是一份很漂亮的“未篡改证明”,可模型吃进去的还是烂输入。 这才是我觉得最有意思的地方。OpenGradient 一直在讲可验证 AI,可 Data Nodes 暴露出来的是另一回事:你可以验证数据被诚实搬运,却验证不了现实是不是被人提前污染。金融代理拿这种价格源调仓,社交代理拿这种刷量数据行动,模型越听话,错得越干净。到最后真出事,节点可以说我没篡改,TEE 可以说我按流程跑了,链上证明也没问题。那责任到底在哪? 还有一点容易忽略。以后大家比的可能不是谁模型更强,而是谁的数据入口更可信。模型越来越容易获得,真正拉开差距的反而是输入的数据。谁能持续拿到高质量的数据,谁的 AI 才有长期优势。 所以我觉得,Data Nodes 真正想占的位置,不是 AI 推理,而是 AI 的数据入口。未来如果越来越多应用把数据先交给 OpenGradient,再进入模型,那 $OPG 抓住的就不是一次推理,而是整个 AI 工作流最前面的那道关口。 #opg $OPG
@OpenGradient 文档里 Data Nodes 这一段看着挺干净:外部 API、数据库、价格源都进 TEE,节点运营商看不到、改不了,还能生成证明。读第一遍像是补上了 AI 推理最缺的那块拼图,读第二遍我就有点发凉——它证明的是数据路上没被偷换,不是数据源头没烂。

如果价格 API 本来就慢半拍,数据库本来就是旧账,X 上的舆情数据早被水军刷成垃圾,Data Node 会怎么做?它不会判断这东西脏不脏,它只会把这口脏饭端得很规范:TEE 里取、签名、出证明、送给模型。最后链上留下的是一份很漂亮的“未篡改证明”,可模型吃进去的还是烂输入。

这才是我觉得最有意思的地方。OpenGradient 一直在讲可验证 AI,可 Data Nodes 暴露出来的是另一回事:你可以验证数据被诚实搬运,却验证不了现实是不是被人提前污染。金融代理拿这种价格源调仓,社交代理拿这种刷量数据行动,模型越听话,错得越干净。到最后真出事,节点可以说我没篡改,TEE 可以说我按流程跑了,链上证明也没问题。那责任到底在哪?

还有一点容易忽略。以后大家比的可能不是谁模型更强,而是谁的数据入口更可信。模型越来越容易获得,真正拉开差距的反而是输入的数据。谁能持续拿到高质量的数据,谁的 AI 才有长期优势。

所以我觉得,Data Nodes 真正想占的位置,不是 AI 推理,而是 AI 的数据入口。未来如果越来越多应用把数据先交给 OpenGradient,再进入模型,那 $OPG 抓住的就不是一次推理,而是整个 AI 工作流最前面的那道关口。
#opg $OPG
·
--
Ver traducción
最近翻@OpenGradient 白皮书的时候,我一直卡在一个问题上:为什么它一直强调 AI Workflow 要“Composable(可组合)”,而不是直接提供一套完整的 AI 服务。 刚开始我以为这是工程问题。模型、工具、数据源拆开,开发者更灵活,生态也更开放。可继续往下看,我突然发现,Composable 真正改变的不是开发方式,而是价值归属。 传统 AI 产品卖的是一个完整能力。模型部署好、工具接好,用户只需要调用结果,平台对最终体验负责。但 OpenGradient 恰恰相反,它把能力拆成一个个独立模块,再交给开发者自己组合。模型可以换,工具可以换,工作流也可以换,看起来选择更多了,可与此同时,系统也把“结果责任”一起拆散了。 这里有个很有意思的变化。当一次 AI 服务失败时,在传统平台里,责任属于平台;可在 OpenGradient 里,模型、工具、工作流都可能来自不同参与者。结果不好,到底是谁的问题?是模型?是工具?还是工作流设计? 看到这里的时候,我突然意识到,Composable 解决的未必只是扩展性,它还重新定义了责任。 因为当能力被拆成模块以后,价值可以拆分,收益可以拆分,但责任也一起被拆分了。 这也是为什么我越来越觉得,OpenGradient 真正建设的未必只是一个开放 AI 网络,而是一套开放的 AI 分工体系。它希望任何人都能贡献模型、工具和工作流,但代价就是,没有任何一个参与者需要对最终结果承担全部责任。 如果这个判断成立,那 Composable 最大的价值就不是“更灵活”,而是把一个完整 AI 产品,变成了一张可以不断重组的协作网络。 但与此同时,它也留下了一个更现实的问题:当所有人都贡献了一部分时,最后到底由谁,为结果负责? #opg $OPG
最近翻@OpenGradient 白皮书的时候,我一直卡在一个问题上:为什么它一直强调 AI Workflow 要“Composable(可组合)”,而不是直接提供一套完整的 AI 服务。

刚开始我以为这是工程问题。模型、工具、数据源拆开,开发者更灵活,生态也更开放。可继续往下看,我突然发现,Composable 真正改变的不是开发方式,而是价值归属。

传统 AI 产品卖的是一个完整能力。模型部署好、工具接好,用户只需要调用结果,平台对最终体验负责。但 OpenGradient 恰恰相反,它把能力拆成一个个独立模块,再交给开发者自己组合。模型可以换,工具可以换,工作流也可以换,看起来选择更多了,可与此同时,系统也把“结果责任”一起拆散了。

这里有个很有意思的变化。当一次 AI 服务失败时,在传统平台里,责任属于平台;可在 OpenGradient 里,模型、工具、工作流都可能来自不同参与者。结果不好,到底是谁的问题?是模型?是工具?还是工作流设计?

看到这里的时候,我突然意识到,Composable 解决的未必只是扩展性,它还重新定义了责任。

因为当能力被拆成模块以后,价值可以拆分,收益可以拆分,但责任也一起被拆分了。

这也是为什么我越来越觉得,OpenGradient 真正建设的未必只是一个开放 AI 网络,而是一套开放的 AI 分工体系。它希望任何人都能贡献模型、工具和工作流,但代价就是,没有任何一个参与者需要对最终结果承担全部责任。

如果这个判断成立,那 Composable 最大的价值就不是“更灵活”,而是把一个完整 AI 产品,变成了一张可以不断重组的协作网络。

但与此同时,它也留下了一个更现实的问题:当所有人都贡献了一部分时,最后到底由谁,为结果负责?
#opg $OPG
·
--
Ver traducción
刷@OpenGradient 的 Model Hub 时,我一直有种很别扭的感觉:它最危险的地方,也许不是模型太少,而是模型看起来太多了。 项目一直在讲开放模型网络、模型可发现、可调用、可组合,Hub 里也堆了大量模型条目,乍看像个链上 AI 商店。可模型数量从来不是价值,需求才是。一个真正成立的模型市场,至少要解决三件事:谁在持续提供独特模型,谁在持续消费这些模型,提供方能不能靠调用量和分成活下去。OpenGradient 现在最尴尬的地方,是它更像在拼命扩充“货架”,却没有证明这些货架上真的有稳定成交。把模型挂上去不难,难的是让别人反复调用;把开源模型搬进 Hub 不难,难的是让创作者在这里赚到比 Hugging Face、本地部署或传统 API 分发更高的钱。 这就把问题拧到了最现实的一层:OpenGradient 到底在做市场,还是在做陈列馆?如果供给端大多只是开源模型再包装,需求端又没有足够强的真实调用场景,那 Model Hub 看起来越繁荣,反而越像一种橱窗幻觉——项目把“模型上架数量”包装成了“网络活性”,把“能被发现”包装成了“能赚到钱”。可这两件事根本不是一回事。你可以挂一千个模型,但如果调用最终还是流向少数官方工作流、示范应用和头部条目,那剩下的大多数模型就不是资产,只是背景板,是用来把“开放智能市场”这句话撑得更好看的道具。 所以我现在越来越怀疑,OpenGradient 最难的不是推理,也不是验证,而是需求冷启动。它真正需要回答的问题不是“还能接入多少模型”,而是“这些模型有没有人愿意持续付第二次、第三次的钱”。如果这个问题答不出来,那 Model Hub 再热闹,也更像链上模型展柜,而不是一个真正能养活供给侧的 AI 市场。 #opg $OPG
@OpenGradient 的 Model Hub 时,我一直有种很别扭的感觉:它最危险的地方,也许不是模型太少,而是模型看起来太多了。

项目一直在讲开放模型网络、模型可发现、可调用、可组合,Hub 里也堆了大量模型条目,乍看像个链上 AI 商店。可模型数量从来不是价值,需求才是。一个真正成立的模型市场,至少要解决三件事:谁在持续提供独特模型,谁在持续消费这些模型,提供方能不能靠调用量和分成活下去。OpenGradient 现在最尴尬的地方,是它更像在拼命扩充“货架”,却没有证明这些货架上真的有稳定成交。把模型挂上去不难,难的是让别人反复调用;把开源模型搬进 Hub 不难,难的是让创作者在这里赚到比 Hugging Face、本地部署或传统 API 分发更高的钱。

这就把问题拧到了最现实的一层:OpenGradient 到底在做市场,还是在做陈列馆?如果供给端大多只是开源模型再包装,需求端又没有足够强的真实调用场景,那 Model Hub 看起来越繁荣,反而越像一种橱窗幻觉——项目把“模型上架数量”包装成了“网络活性”,把“能被发现”包装成了“能赚到钱”。可这两件事根本不是一回事。你可以挂一千个模型,但如果调用最终还是流向少数官方工作流、示范应用和头部条目,那剩下的大多数模型就不是资产,只是背景板,是用来把“开放智能市场”这句话撑得更好看的道具。

所以我现在越来越怀疑,OpenGradient 最难的不是推理,也不是验证,而是需求冷启动。它真正需要回答的问题不是“还能接入多少模型”,而是“这些模型有没有人愿意持续付第二次、第三次的钱”。如果这个问题答不出来,那 Model Hub 再热闹,也更像链上模型展柜,而不是一个真正能养活供给侧的 AI 市场。
#opg $OPG
·
--
Ver traducción
@OpenGradient 的Temporary Trust Gap设计点让我觉得很有趣,大部分项目写白皮书的时候,都在想办法证明自己没有风险。可 OpenGradient 不一样,它直接承认系统里存在一个信任缺口。乍看很诚实,但越想越有意思,因为承认风险,和解决风险,从来不是一回事。 这个逻辑其实相对比较简单,在支付、推理、验证最终完成之前,系统会经历一个短暂的异步阶段。在这个阶段里,用户需要相信后续流程会按预期完成。 这就很微妙了,传统区块链一直强调“不需要信任任何人”,相信代码、共识和链上状态就够了。可 OpenGradient 在这里承认,至少在某个时间窗口里,你必须先相信系统,然后才能等到系统证明自己值得相信。 这里我觉得它真正写的可能不是安全设计,而是责任边界。因为从风险被公开写出来的那一刻开始,系统已经提前告诉你:这里有一个缺口。如果未来真的出问题,它不是隐藏风险,而是公开风险。表面上这是透明度,反过来看,也是一种责任转移。 所以看完这个之后我感觉OpenGradient 真正在定义的,可能不是系统有多可信,而是系统在哪些地方暂时不可信。很多项目喜欢讲自己解决了什么问题,它反而先告诉你哪些问题还没有被完全解决。如果这个判断成立,第10.2节最重要的地方就不是 Trust Gap 本身,而是它暴露了一个底层事实:OpenGradient 出售的并不是已经完成的信任,而是一套正在逼近信任的过程。而在这个过程结束之前,承担那段空白风险的人,始终是用户。 #opg $OPG
@OpenGradient 的Temporary Trust Gap设计点让我觉得很有趣,大部分项目写白皮书的时候,都在想办法证明自己没有风险。可 OpenGradient 不一样,它直接承认系统里存在一个信任缺口。乍看很诚实,但越想越有意思,因为承认风险,和解决风险,从来不是一回事。

这个逻辑其实相对比较简单,在支付、推理、验证最终完成之前,系统会经历一个短暂的异步阶段。在这个阶段里,用户需要相信后续流程会按预期完成。

这就很微妙了,传统区块链一直强调“不需要信任任何人”,相信代码、共识和链上状态就够了。可 OpenGradient 在这里承认,至少在某个时间窗口里,你必须先相信系统,然后才能等到系统证明自己值得相信。

这里我觉得它真正写的可能不是安全设计,而是责任边界。因为从风险被公开写出来的那一刻开始,系统已经提前告诉你:这里有一个缺口。如果未来真的出问题,它不是隐藏风险,而是公开风险。表面上这是透明度,反过来看,也是一种责任转移。

所以看完这个之后我感觉OpenGradient 真正在定义的,可能不是系统有多可信,而是系统在哪些地方暂时不可信。很多项目喜欢讲自己解决了什么问题,它反而先告诉你哪些问题还没有被完全解决。如果这个判断成立,第10.2节最重要的地方就不是 Trust Gap 本身,而是它暴露了一个底层事实:OpenGradient 出售的并不是已经完成的信任,而是一套正在逼近信任的过程。而在这个过程结束之前,承担那段空白风险的人,始终是用户。
#opg $OPG
·
--
Ver traducción
@OpenGradient 里的Facilitator这一角色一直让我觉得不对劲,正常理解里一个去中心化 AI 网络应该用户发请求、节点执行、验证层确认结果。可 OpenGradient 偏偏在中间塞了一个 Facilitator。白皮书把它写成协调层,可协调这件事本身就很有意思。因为协调意味着它知道谁发起请求、谁支付了 OPG、请求什么时候进入系统、后面又被发给了哪个节点。推理节点只知道自己在算什么,验证节点只知道自己在验什么,只有 Facilitator 同时看见整个流程。 看到这里的时候,我突然意识到一个问题。OpenGradient 一直在强调去中心化计算,可它真正难解决的从来不是计算,而是调度。GPU 可以分散,模型可以分散,验证可以分散,但任务总要有人分配。谁决定任务流向哪里,谁就掌握了系统最核心的信息。 这也是为什么我越来越觉得 Facilitator 不是一个普通模块,而是整个网络的交通枢纽。它不生产结果,不验证结果,却决定结果如何发生。传统互联网平台最值钱的也不是服务器,而是信息流入口。因为谁控制入口,谁就控制流向。放到 OpenGradient 身上也是一样。如果推理节点少一个,系统还能继续运行;如果验证节点换一个,结果照样可以验证。但如果协调层失灵,整个流程都会停下来。 现在我最大的疑问不是模型够不够强,而是 OpenGradient 是否真的完成了去中心化。因为从架构上看,算力被分散了,验证被分散了,可协调权并没有被分散。它只是被包装成了一个叫 Facilitator 的角色。 如果这个判断成立,那么 OpenGradient 最值得关注的可能不是推理层,而是协调层。因为未来真正决定网络权力归属的,也许不是谁拥有最多 GPU,而是谁拥有分配 GPU 的权力。 #opg $OPG
@OpenGradient 里的Facilitator这一角色一直让我觉得不对劲,正常理解里一个去中心化 AI 网络应该用户发请求、节点执行、验证层确认结果。可 OpenGradient 偏偏在中间塞了一个 Facilitator。白皮书把它写成协调层,可协调这件事本身就很有意思。因为协调意味着它知道谁发起请求、谁支付了 OPG、请求什么时候进入系统、后面又被发给了哪个节点。推理节点只知道自己在算什么,验证节点只知道自己在验什么,只有 Facilitator 同时看见整个流程。

看到这里的时候,我突然意识到一个问题。OpenGradient 一直在强调去中心化计算,可它真正难解决的从来不是计算,而是调度。GPU 可以分散,模型可以分散,验证可以分散,但任务总要有人分配。谁决定任务流向哪里,谁就掌握了系统最核心的信息。

这也是为什么我越来越觉得 Facilitator 不是一个普通模块,而是整个网络的交通枢纽。它不生产结果,不验证结果,却决定结果如何发生。传统互联网平台最值钱的也不是服务器,而是信息流入口。因为谁控制入口,谁就控制流向。放到 OpenGradient 身上也是一样。如果推理节点少一个,系统还能继续运行;如果验证节点换一个,结果照样可以验证。但如果协调层失灵,整个流程都会停下来。

现在我最大的疑问不是模型够不够强,而是 OpenGradient 是否真的完成了去中心化。因为从架构上看,算力被分散了,验证被分散了,可协调权并没有被分散。它只是被包装成了一个叫 Facilitator 的角色。

如果这个判断成立,那么 OpenGradient 最值得关注的可能不是推理层,而是协调层。因为未来真正决定网络权力归属的,也许不是谁拥有最多 GPU,而是谁拥有分配 GPU 的权力。
#opg $OPG
·
--
Recientemente, al mirar el mecanismo de diseño de OpenGradient, me quedé atascado en un problema: ¿por qué un mismo pedido de inferencia permite que múltiples nodos se ejecuten repetidamente? Desde la perspectiva de la IA tradicional, esto parece un desperdicio; el cálculo repetido solo aumentaría los costos. Pero el diseño de OpenGradient no evita la repetición, sino que la genera activamente. Al principio pensé que era un mecanismo de tolerancia a fallos, pero al seguir investigando, de repente me di cuenta de que su objetivo no era la estabilidad, sino la diferencia. Porque si solo hay una inferencia, el resultado no es comparable, pero cuando múltiples nodos realizan inferencias sobre la misma entrada, el sistema naturalmente genera un conjunto de resultados diferentes, y estos resultados entran en competencia. Al darme cuenta de esto, me di cuenta de que lo que realmente depende de @OpenGradient no es la respuesta correcta, sino la diferencia entre las respuestas. Diferentes nodos, diferentes modelos, diferentes entornos de ejecución, generarán diferentes salidas, y la Capa de Verificación no solo valida si son correctas o no, sino que filtra entre estos resultados candidatos. Es decir, el objeto de validación del sistema no es un único resultado, sino un conjunto de resultados. Si esta estructura es válida, entonces el rol de la inferencia cambia. Ya no se trata de producir respuestas, sino de generar un espacio de candidatos. El verdadero valor no está en una salida específica, sino en la estructura comparable que se forma entre estas salidas. En este punto, la cuestión cambia. La IA tradicional es: una inferencia → un resultado → fin. OpenGradient es: múltiples inferencias → múltiples resultados → entra en competencia → luego el sistema filtra. Cuanto más lo pensaba, más me daba cuenta de que esto realmente redefine la "inferenciación" en sí. La inferencia ya no es calcular una respuesta, sino generar un conjunto de posibilidades que el sistema puede comparar. Y la función de la Capa de Verificación no es solo juzgar correcto o incorrecto, sino establecer reglas de clasificación para que estos resultados entren en consenso de la red. Así que si miramos más a fondo, lo que realmente depende de OpenGradient no es la potencia de cálculo, ni los modelos, sino la "estructuración de las diferencias". Sin diferencias, no hay filtrado; sin múltiples resultados, no hay base para formar consenso. Si este juicio se sostiene, entonces el significado de $OPG también cambia: no es comprar un resultado de inferencia, sino comprar una oportunidad para entrar en un "sistema de competencia de múltiples resultados". #opg $OPG
Recientemente, al mirar el mecanismo de diseño de OpenGradient, me quedé atascado en un problema: ¿por qué un mismo pedido de inferencia permite que múltiples nodos se ejecuten repetidamente?

Desde la perspectiva de la IA tradicional, esto parece un desperdicio; el cálculo repetido solo aumentaría los costos. Pero el diseño de OpenGradient no evita la repetición, sino que la genera activamente.

Al principio pensé que era un mecanismo de tolerancia a fallos, pero al seguir investigando, de repente me di cuenta de que su objetivo no era la estabilidad, sino la diferencia. Porque si solo hay una inferencia, el resultado no es comparable, pero cuando múltiples nodos realizan inferencias sobre la misma entrada, el sistema naturalmente genera un conjunto de resultados diferentes, y estos resultados entran en competencia.

Al darme cuenta de esto, me di cuenta de que lo que realmente depende de @OpenGradient no es la respuesta correcta, sino la diferencia entre las respuestas. Diferentes nodos, diferentes modelos, diferentes entornos de ejecución, generarán diferentes salidas, y la Capa de Verificación no solo valida si son correctas o no, sino que filtra entre estos resultados candidatos. Es decir, el objeto de validación del sistema no es un único resultado, sino un conjunto de resultados.

Si esta estructura es válida, entonces el rol de la inferencia cambia. Ya no se trata de producir respuestas, sino de generar un espacio de candidatos.

El verdadero valor no está en una salida específica, sino en la estructura comparable que se forma entre estas salidas.

En este punto, la cuestión cambia.

La IA tradicional es: una inferencia → un resultado → fin.

OpenGradient es: múltiples inferencias → múltiples resultados → entra en competencia → luego el sistema filtra.

Cuanto más lo pensaba, más me daba cuenta de que esto realmente redefine la "inferenciación" en sí.

La inferencia ya no es calcular una respuesta, sino generar un conjunto de posibilidades que el sistema puede comparar.

Y la función de la Capa de Verificación no es solo juzgar correcto o incorrecto, sino establecer reglas de clasificación para que estos resultados entren en consenso de la red.

Así que si miramos más a fondo, lo que realmente depende de OpenGradient no es la potencia de cálculo, ni los modelos, sino la "estructuración de las diferencias".

Sin diferencias, no hay filtrado; sin múltiples resultados, no hay base para formar consenso.

Si este juicio se sostiene, entonces el significado de $OPG también cambia: no es comprar un resultado de inferencia, sino comprar una oportunidad para entrar en un "sistema de competencia de múltiples resultados".
#opg $OPG
·
--
Ver traducción
最近翻 @OpenGradient 白皮书的时候,我被一个细节卡住了。第5章那套支付→推理→证明的流程里,系统反复强调“证明已生成”,却很少讨论另一件事:如果证明生成了,但没人验证,它还有价值吗? 刚开始我觉得这是废话。证明存在,价值自然存在。但后来发现不是这样。因为 OpenGradient 的整个网络里,真正稀缺的可能不是推理能力,而是验证能力。 推理节点只要有 GPU 就能不断增加,模型也能持续部署。但验证层不一样,它决定哪些结果能够进入系统,哪些结果能够被接受。换句话说,推理负责生产结果,验证负责赋予结果价值。 这里有个很有意思的矛盾。大部分 AI 项目都在卷推理成本,模型更快、GPU更多、吞吐量更高,大家默认计算能力越强,网络价值越大。但 OpenGradient 的结构反而说明了一件事:如果验证能力跟不上,推理能力增长得越快,无效结果增长得也越快。 这就像一个工厂不断生产商品,却没有质检部门。产量确实上去了,但没人知道哪些商品能够进入市场。 看到这里的时候,我突然意识到,OpenGradient 可能做了一个和传统 AI 完全不同的判断。 传统 AI 相信供给创造价值,模型越强,价值越大。 OpenGradient 相信筛选创造价值。结果再多,没有验证也只是结果;只有经过验证,结果才会变成网络认可的资产。 所以我越来越觉得,Verification Layer 真正决定的不是结果是否存在,而是结果是否有资格进入网络经济。 如果这个判断成立,那么 OpenGradient 最核心的资源可能根本不是 GPU,也不是模型,而是验证权。 因为在 OpenGradient 的逻辑里,计算不会天然产生价值,被网络接受的计算才会产生价值。#opg $OPG
最近翻 @OpenGradient 白皮书的时候,我被一个细节卡住了。第5章那套支付→推理→证明的流程里,系统反复强调“证明已生成”,却很少讨论另一件事:如果证明生成了,但没人验证,它还有价值吗?

刚开始我觉得这是废话。证明存在,价值自然存在。但后来发现不是这样。因为 OpenGradient 的整个网络里,真正稀缺的可能不是推理能力,而是验证能力。

推理节点只要有 GPU 就能不断增加,模型也能持续部署。但验证层不一样,它决定哪些结果能够进入系统,哪些结果能够被接受。换句话说,推理负责生产结果,验证负责赋予结果价值。

这里有个很有意思的矛盾。大部分 AI 项目都在卷推理成本,模型更快、GPU更多、吞吐量更高,大家默认计算能力越强,网络价值越大。但 OpenGradient 的结构反而说明了一件事:如果验证能力跟不上,推理能力增长得越快,无效结果增长得也越快。

这就像一个工厂不断生产商品,却没有质检部门。产量确实上去了,但没人知道哪些商品能够进入市场。

看到这里的时候,我突然意识到,OpenGradient 可能做了一个和传统 AI 完全不同的判断。

传统 AI 相信供给创造价值,模型越强,价值越大。

OpenGradient 相信筛选创造价值。结果再多,没有验证也只是结果;只有经过验证,结果才会变成网络认可的资产。

所以我越来越觉得,Verification Layer 真正决定的不是结果是否存在,而是结果是否有资格进入网络经济。

如果这个判断成立,那么 OpenGradient 最核心的资源可能根本不是 GPU,也不是模型,而是验证权。

因为在 OpenGradient 的逻辑里,计算不会天然产生价值,被网络接受的计算才会产生价值。#opg $OPG
·
--
Ver traducción
最近看@OpenGradient OpenGradient 的时候我一直在想为什么模型不能直接参与网络,而必须先经过 Hosting Layer。如果只是为了存储模型,其实没必要专门设计一层 Hosting Layer。因为在传统 AI 世界里,模型一旦完成部署,就天然拥有运行权。开发者训练模型、部署模型、用户调用模型,整个过程由模型拥有者决定。 但 OpenGradient 的逻辑不是这样,在它的架构里,模型存在并不等于模型能够参与网络。模型必须先进入 Hosting Layer,成为网络认可的对象,之后才能进入推理和验证流程。 看到这里的时候,我突然意识到,OpenGradient 真正在改变的可能不是模型运行方式,而是模型运行权的来源。 传统 AI 里,运行权来自模型拥有者。谁控制模型,谁决定模型是否被使用。但在开放网络里,如果任何模型都能直接参与系统,那么网络其实无法确认自己面对的到底是什么模型。版本变化、权重替换甚至模型本身的变更,最终都会影响后面的推理和验证。 所以 OpenGradient 多做了一步。 它没有默认模型拥有运行权,而是把运行权交给网络。模型先被网络接纳,然后才能被网络使用。 这个变化看起来只是多了一层 Hosting Layer,但背后的权力结构已经不同了。过去模型拥有者决定模型能否运行,现在网络决定模型能否运行。 所以我越来越觉得,Hosting Layer 管理的并不是模型存储,而是模型进入网络的资格。 因为从 OpenGradient 的视角看,真正重要的不是模型是否存在,而是模型是否被网络承认。 而这背后对应着一个更底层的问题:未来 AI 网络里,谁有权决定哪些模型能够参与系统。 如果这个判断是对的,那么 Hosting Layer 的意义就不仅仅是托管模型,而是在为整个网络建立第一道准入规则。 #opg $OPG
最近看@OpenGradient OpenGradient 的时候我一直在想为什么模型不能直接参与网络,而必须先经过 Hosting Layer。如果只是为了存储模型,其实没必要专门设计一层 Hosting Layer。因为在传统 AI 世界里,模型一旦完成部署,就天然拥有运行权。开发者训练模型、部署模型、用户调用模型,整个过程由模型拥有者决定。

但 OpenGradient 的逻辑不是这样,在它的架构里,模型存在并不等于模型能够参与网络。模型必须先进入 Hosting Layer,成为网络认可的对象,之后才能进入推理和验证流程。

看到这里的时候,我突然意识到,OpenGradient 真正在改变的可能不是模型运行方式,而是模型运行权的来源。

传统 AI 里,运行权来自模型拥有者。谁控制模型,谁决定模型是否被使用。但在开放网络里,如果任何模型都能直接参与系统,那么网络其实无法确认自己面对的到底是什么模型。版本变化、权重替换甚至模型本身的变更,最终都会影响后面的推理和验证。

所以 OpenGradient 多做了一步。

它没有默认模型拥有运行权,而是把运行权交给网络。模型先被网络接纳,然后才能被网络使用。

这个变化看起来只是多了一层 Hosting Layer,但背后的权力结构已经不同了。过去模型拥有者决定模型能否运行,现在网络决定模型能否运行。

所以我越来越觉得,Hosting Layer 管理的并不是模型存储,而是模型进入网络的资格。

因为从 OpenGradient 的视角看,真正重要的不是模型是否存在,而是模型是否被网络承认。

而这背后对应着一个更底层的问题:未来 AI 网络里,谁有权决定哪些模型能够参与系统。

如果这个判断是对的,那么 Hosting Layer 的意义就不仅仅是托管模型,而是在为整个网络建立第一道准入规则。
#opg $OPG
·
--
Ver traducción
最近看@OpenGradient 的时候,我一直在想一个问题:为什么它要同时管理模型和计算。 过去几年 AI 赛道基本分成两条路。一条认为模型最重要,谁拥有更强模型,谁就拥有价值;另一条认为算力最重要,只要有 GPU,就能不断产生价值。所以很多项目不是做模型市场,就是做算力市场。 但 OpenGradient 没有站在任何一边。 它既要托管模型,又要组织推理,还要验证结果。如果它认为模型才是核心,完全可以做成模型分发网络;如果它认为算力才是核心,直接做推理市场就够了。可它偏偏把两者放进同一个系统。 看到这里的时候,我突然意识到,它真正关注的可能不是模型,也不是算力,而是两者之间的关系。 传统 AI 世界里,模型和计算几乎是绑定的。拥有模型的人通常也拥有运行模型的能力,模型在哪里,计算就在哪里。这样虽然效率高,但整个系统的价值最终会集中在少数参与者手里。 OpenGradient 的做法恰恰相反。它把模型托管、推理执行和结果验证拆成独立层,让模型和计算第一次成为两种独立资源。模型不一定属于计算者,计算者也不一定拥有模型。 这个变化背后其实是在回答一个更大的问题:AI 网络的价值到底来自哪里? 如果价值只来自模型,网络最终会变成模型垄断;如果价值只来自算力,网络最后会变成 GPU 市场。可 OpenGradient 的架构说明,它并不认为价值来自某一个环节。 因为真正产生价值的,不是模型本身,也不是计算本身,而是模型与计算不断匹配、调用和验证的过程。 所以我越来越觉得,OpenGradient 真正建设的不是模型网络,也不是算力网络,而是一层连接模型与计算的基础设施。它试图解决的不是谁拥有资源,而是如何让资源之间持续协作。 #opg#opg $OPG
最近看@OpenGradient 的时候,我一直在想一个问题:为什么它要同时管理模型和计算。

过去几年 AI 赛道基本分成两条路。一条认为模型最重要,谁拥有更强模型,谁就拥有价值;另一条认为算力最重要,只要有 GPU,就能不断产生价值。所以很多项目不是做模型市场,就是做算力市场。

但 OpenGradient 没有站在任何一边。

它既要托管模型,又要组织推理,还要验证结果。如果它认为模型才是核心,完全可以做成模型分发网络;如果它认为算力才是核心,直接做推理市场就够了。可它偏偏把两者放进同一个系统。

看到这里的时候,我突然意识到,它真正关注的可能不是模型,也不是算力,而是两者之间的关系。

传统 AI 世界里,模型和计算几乎是绑定的。拥有模型的人通常也拥有运行模型的能力,模型在哪里,计算就在哪里。这样虽然效率高,但整个系统的价值最终会集中在少数参与者手里。

OpenGradient 的做法恰恰相反。它把模型托管、推理执行和结果验证拆成独立层,让模型和计算第一次成为两种独立资源。模型不一定属于计算者,计算者也不一定拥有模型。

这个变化背后其实是在回答一个更大的问题:AI 网络的价值到底来自哪里?

如果价值只来自模型,网络最终会变成模型垄断;如果价值只来自算力,网络最后会变成 GPU 市场。可 OpenGradient 的架构说明,它并不认为价值来自某一个环节。

因为真正产生价值的,不是模型本身,也不是计算本身,而是模型与计算不断匹配、调用和验证的过程。

所以我越来越觉得,OpenGradient 真正建设的不是模型网络,也不是算力网络,而是一层连接模型与计算的基础设施。它试图解决的不是谁拥有资源,而是如何让资源之间持续协作。

#opg#opg $OPG
·
--
Ver traducción
最近看 @OpenGradient 白皮书的时候,我被一个细节卡住了:为什么它一定要把 Model Hosting 单独拿出来做一层? 刚开始我以为这只是部署问题。模型总得有地方存放,总得有节点运行,这看起来没什么特别的。但后来我发现,如果只是为了存模型,根本没必要专门设计 Hosting Layer。 因为传统 AI 里模型和推理本来就是绑定的,但 OpenGradient 偏偏把这件事拆开了。模型归 Hosting Layer,推理由 Inference Layer 完成,最后还有 Verification Layer 负责确认结果。 大胆猜测一下,它拆开的可能不是功能,而是垄断。 传统 AI 最大的问题之一,其实不是模型强弱,而是谁控制模型。因为一旦模型和推理绑定在一起,模型拥有者天然就拥有执行权和结果输出权。你无法验证模型有没有被修改,也无法验证它是不是按照原来的方式运行。所以 OpenGradient 把模型从执行环境里剥离出来,这样一来托管模型的人不一定负责推理,负责推理的人也不一定拥有模型,模型、执行和验证开始变成三个独立角色。 其实我觉得这个设计改变的是 AI 网络里的权力流向,过去模型拥有者是整个系统的中心,而 OpenGradient 的方向恰恰相反,它不断削弱单个参与者的控制力,把模型权、执行权和验证权拆散,让任何一个角色都无法单独决定最终结果。 这也是为什么我越来越觉得 OpenGradient 真正在建设的不是推理网络,而是一套去中心化的 AI 权力结构。 很多人看到的是 Hosting Layer。 我看到的反而是它背后的假设: 未来最大的风险可能不是没有模型,而是模型被少数人控制。 如果这个判断是对的,那么 Hosting Layer 的意义就不只是存储模型,而是在为整个网络建立第一层权力隔离。 因为从模型被拆出执行环境的那一刻开始,AI 的控制权就不再天然属于模型拥有者了。 #opg #opg $OPG
最近看 @OpenGradient 白皮书的时候,我被一个细节卡住了:为什么它一定要把 Model Hosting 单独拿出来做一层?

刚开始我以为这只是部署问题。模型总得有地方存放,总得有节点运行,这看起来没什么特别的。但后来我发现,如果只是为了存模型,根本没必要专门设计 Hosting Layer。

因为传统 AI 里模型和推理本来就是绑定的,但 OpenGradient 偏偏把这件事拆开了。模型归 Hosting Layer,推理由 Inference Layer 完成,最后还有 Verification Layer 负责确认结果。

大胆猜测一下,它拆开的可能不是功能,而是垄断。

传统 AI 最大的问题之一,其实不是模型强弱,而是谁控制模型。因为一旦模型和推理绑定在一起,模型拥有者天然就拥有执行权和结果输出权。你无法验证模型有没有被修改,也无法验证它是不是按照原来的方式运行。所以 OpenGradient 把模型从执行环境里剥离出来,这样一来托管模型的人不一定负责推理,负责推理的人也不一定拥有模型,模型、执行和验证开始变成三个独立角色。

其实我觉得这个设计改变的是 AI 网络里的权力流向,过去模型拥有者是整个系统的中心,而 OpenGradient 的方向恰恰相反,它不断削弱单个参与者的控制力,把模型权、执行权和验证权拆散,让任何一个角色都无法单独决定最终结果。

这也是为什么我越来越觉得 OpenGradient 真正在建设的不是推理网络,而是一套去中心化的 AI 权力结构。

很多人看到的是 Hosting Layer。

我看到的反而是它背后的假设:

未来最大的风险可能不是没有模型,而是模型被少数人控制。

如果这个判断是对的,那么 Hosting Layer 的意义就不只是存储模型,而是在为整个网络建立第一层权力隔离。

因为从模型被拆出执行环境的那一刻开始,AI 的控制权就不再天然属于模型拥有者了。

#opg
#opg $OPG
·
--
Ver traducción
最近重新看@OpenGradient 的时候,我突然发现 Verification Layer 这个东西可能被很多人理解浅了。大部分人看到这一层,第一反应都是防作弊,防止推理节点作恶,保证结果正确。但如果只是为了防作弊,其实根本没必要把它放到整个架构的核心位置。因为 Verification Layer 存在的前提,本身就意味着 OpenGradient 做出了一个判断:推理结果是不可信的。 这就有意思了。过去整个 AI 行业都在想办法提高模型可信度,更大的参数、更好的数据、更强的训练方法,本质上都在回答如何让用户更相信模型。但 OpenGradient 的思路完全反过来了。它没有试图证明模型可信,而是直接默认模型不可信,然后围绕这个前提设计网络。 传统 AI 的核心资产是模型本身,谁拥有更强模型,谁就拥有更大的话语权。而在 OpenGradient 里,Inference Layer 负责生成结果,但生成结果不等于拥有结果。多个节点可以同时推理,同一个问题甚至会出现多个答案,而这些答案最终能不能成立,并不取决于模型本身,而取决于 Verification Layer 是否接受。 看到这里我突然意识到,OpenGradient 真正在拆的可能不是推理流程,而是 AI 世界最根本的一种权力结构。过去模型同时拥有计算权和结果解释权,模型说什么,答案就是什么。而在 OpenGradient 里,推理节点拥有计算权,却失去了最终解释权;验证层不负责计算,却拥有结果确认权。 所以我越来越觉得,OpenGradient 真正建设的不是 AI 网络,而是一套让不可信模型也能共同工作的基础设施。因为从 Verification Layer 出现的那一刻开始,它就在回答一个问题:如果未来没有任何一个模型值得被完全信任,系统还能不能持续产生可信结果。 如果这个判断是对的,那么 $OPG 最有价值的东西可能不是模型,而是这套建立在“不信任模型”之上的验证结构。 #opg $OPG
最近重新看@OpenGradient 的时候,我突然发现 Verification Layer 这个东西可能被很多人理解浅了。大部分人看到这一层,第一反应都是防作弊,防止推理节点作恶,保证结果正确。但如果只是为了防作弊,其实根本没必要把它放到整个架构的核心位置。因为 Verification Layer 存在的前提,本身就意味着 OpenGradient 做出了一个判断:推理结果是不可信的。

这就有意思了。过去整个 AI 行业都在想办法提高模型可信度,更大的参数、更好的数据、更强的训练方法,本质上都在回答如何让用户更相信模型。但 OpenGradient 的思路完全反过来了。它没有试图证明模型可信,而是直接默认模型不可信,然后围绕这个前提设计网络。

传统 AI 的核心资产是模型本身,谁拥有更强模型,谁就拥有更大的话语权。而在 OpenGradient 里,Inference Layer 负责生成结果,但生成结果不等于拥有结果。多个节点可以同时推理,同一个问题甚至会出现多个答案,而这些答案最终能不能成立,并不取决于模型本身,而取决于 Verification Layer 是否接受。

看到这里我突然意识到,OpenGradient 真正在拆的可能不是推理流程,而是 AI 世界最根本的一种权力结构。过去模型同时拥有计算权和结果解释权,模型说什么,答案就是什么。而在 OpenGradient 里,推理节点拥有计算权,却失去了最终解释权;验证层不负责计算,却拥有结果确认权。

所以我越来越觉得,OpenGradient 真正建设的不是 AI 网络,而是一套让不可信模型也能共同工作的基础设施。因为从 Verification Layer 出现的那一刻开始,它就在回答一个问题:如果未来没有任何一个模型值得被完全信任,系统还能不能持续产生可信结果。

如果这个判断是对的,那么 $OPG 最有价值的东西可能不是模型,而是这套建立在“不信任模型”之上的验证结构。
#opg $OPG
·
--
Recientemente, cuando miré @OpenGradient , me di cuenta de que la misma solicitud de IA podría ser inferida simultáneamente por múltiples nodos. Mi primera reacción fue que era un desperdicio, ya que la inferencia de IA es una de las etapas más costosas, y calcular repetidamente el mismo problema parece poco económico y poco eficiente. Pero luego me di cuenta de que OpenGradient no está optimizando la inferencia, sino reestructurando 'cómo se generan los resultados'. La IA tradicional solo tiene un camino: cálculo del modelo y luego salida de la respuesta. Quien se encarga del cálculo, define el resultado. Los usuarios confían en el modelo, y en esencia, también están confiando en que el modelo tiene el derecho final de interpretación. OpenGradient ha descompuesto esta cuestión. La Capa de Inferencia se encarga de la inferencia, generando resultados de manera independiente en múltiples nodos; la Capa de Verificación no participa en el cálculo, solo se encarga de validar y confirmar los resultados. De esta forma, los nodos de inferencia ya no deciden la respuesta final, sino que proporcionan resultados candidatos. Este cambio puede parecer pequeño, pero la lógica detrás es completamente diferente. En los sistemas de IA del pasado, el poder de cálculo y el poder de confirmación del resultado eran lo mismo. Lo que el modelo calculaba, eso era la respuesta. Pero OpenGradient intenta separar esos dos poderes. Esta es también la razón por la que acepta el cálculo repetido. Porque estas inferencias adicionales no son para obtener más respuestas, sino para generar evidencia verificable. Solo cuando múltiples resultados independientes existen al mismo tiempo, la capa de verificación tiene sentido. Al llegar aquí, de repente me di cuenta de que lo que OpenGradient realmente está resolviendo podría no ser el problema del cálculo de IA, sino el problema de confianza en la IA. La confianza en la IA tradicional se basa en el modelo mismo. La confianza en OpenGradient se basa en el proceso de verificación. El modelo se encarga de generar resultados, la capa de verificación se encarga de confirmar resultados. La respuesta final no proviene de un solo modelo, sino de todo el mecanismo de verificación. Si esta lógica puede funcionar, entonces lo que OpenGradient está cambiando no es solo la forma de inferencia, sino la estructura de poder más fundamental del sistema de IA. Porque en la IA tradicional, el modelo tiene naturalmente el derecho de interpretación del resultado; mientras que en OpenGradient, el derecho final de interpretación se otorga a la capa de verificación. #opg $OPG
Recientemente, cuando miré @OpenGradient , me di cuenta de que la misma solicitud de IA podría ser inferida simultáneamente por múltiples nodos. Mi primera reacción fue que era un desperdicio, ya que la inferencia de IA es una de las etapas más costosas, y calcular repetidamente el mismo problema parece poco económico y poco eficiente.

Pero luego me di cuenta de que OpenGradient no está optimizando la inferencia, sino reestructurando 'cómo se generan los resultados'.

La IA tradicional solo tiene un camino: cálculo del modelo y luego salida de la respuesta. Quien se encarga del cálculo, define el resultado. Los usuarios confían en el modelo, y en esencia, también están confiando en que el modelo tiene el derecho final de interpretación.

OpenGradient ha descompuesto esta cuestión.

La Capa de Inferencia se encarga de la inferencia, generando resultados de manera independiente en múltiples nodos; la Capa de Verificación no participa en el cálculo, solo se encarga de validar y confirmar los resultados. De esta forma, los nodos de inferencia ya no deciden la respuesta final, sino que proporcionan resultados candidatos.

Este cambio puede parecer pequeño, pero la lógica detrás es completamente diferente.

En los sistemas de IA del pasado, el poder de cálculo y el poder de confirmación del resultado eran lo mismo. Lo que el modelo calculaba, eso era la respuesta. Pero OpenGradient intenta separar esos dos poderes.

Esta es también la razón por la que acepta el cálculo repetido.

Porque estas inferencias adicionales no son para obtener más respuestas, sino para generar evidencia verificable. Solo cuando múltiples resultados independientes existen al mismo tiempo, la capa de verificación tiene sentido.

Al llegar aquí, de repente me di cuenta de que lo que OpenGradient realmente está resolviendo podría no ser el problema del cálculo de IA, sino el problema de confianza en la IA.

La confianza en la IA tradicional se basa en el modelo mismo.

La confianza en OpenGradient se basa en el proceso de verificación.

El modelo se encarga de generar resultados, la capa de verificación se encarga de confirmar resultados. La respuesta final no proviene de un solo modelo, sino de todo el mecanismo de verificación.

Si esta lógica puede funcionar, entonces lo que OpenGradient está cambiando no es solo la forma de inferencia, sino la estructura de poder más fundamental del sistema de IA.

Porque en la IA tradicional, el modelo tiene naturalmente el derecho de interpretación del resultado; mientras que en OpenGradient, el derecho final de interpretación se otorga a la capa de verificación.
#opg $OPG
·
--
He estado revisando el whitepaper de @OpenGradient estos últimos días, y hay un punto que no deja de rondar mi cabeza: en realidad, no se trata de construir "infraestructura de IA", sino más bien de cambiar la forma en que funciona la IA. Al principio, es fácil pensar que se trata de implementar modelos distribuidos, pero al profundizar, te das cuenta de que lo que realmente se está moviendo no es el método de implementación, sino la lógica de generación de resultados de inferencia. En la IA tradicional, la inferencia es unidireccional, una entrada corresponde a una salida del modelo, y el sistema asume que esta salida es confiable. El problema es que esta confianza depende completamente del modelo en sí, sin restricciones externas. Lo primero que hace #opg es romper esa unicidad del camino. La misma entrada no pasa solo por un modelo, sino que se distribuye a múltiples nodos de inferencia, y cada nodo puede generar resultados de manera independiente. Así, la salida ya no es única, sino que se genera un conjunto de resultados candidatos. Al principio pensé que esto solo mejoraba la robustez, pero al seguir investigando, me di cuenta de que la clave no está en la cantidad, sino en el siguiente paso, porque estos resultados candidatos no se devuelven directamente al usuario, sino que entran en una capa de validación. La capa de validación no se encarga de calcular, sino de juzgar la consistencia. Es decir, el sistema ya no pregunta cuál modelo es correcto, sino cuáles resultados son estructuralmente consistentes. He estado reflexionando sobre esto durante mucho tiempo, y de repente me di cuenta de que realmente está cambiando la hipótesis básica de la IA; este paso es crucial porque, una vez que los resultados de inferencia deben pasar por la capa de validación para ser válidos, la salida de la IA ya no es un resultado generado, sino un resultado de consenso. Siguiendo adelante y analizando la capa de gestión de modelos, también se da cuenta de que no es simplemente almacenar modelos; el modelo en sí es reemplazable/versionable, y cada llamada puede provenir de diferentes nodos. Todo el sistema se asemeja más a un flujo constante en lugar de una operación fija. Así, al combinar todo esto, la estructura de OpenGradient se vuelve muy clara: la capa de inferencia se encarga de generar diferencias, la capa de validación se encarga de digerir las diferencias, y la capa de gestión se encarga de mantener la reemplazabilidad del modelo. Así que cuanto más lo pienso, más creo que lo que realmente está cambiando no son las capacidades de la IA, sino la naturaleza de los resultados de la IA. Antes, la salida de la IA era un punto; ahora, la salida de la IA se convierte en un estado verificado. Si este mecanismo es válido, entonces $OPG no está haciendo que la IA sea más poderosa, sino que está transformando la IA de un sistema de decisión de modelo único a un sistema de consenso de múltiples nodos, y este cambio en sí es más fundamental que el tamaño del modelo.
He estado revisando el whitepaper de @OpenGradient estos últimos días, y hay un punto que no deja de rondar mi cabeza: en realidad, no se trata de construir "infraestructura de IA", sino más bien de cambiar la forma en que funciona la IA.

Al principio, es fácil pensar que se trata de implementar modelos distribuidos, pero al profundizar, te das cuenta de que lo que realmente se está moviendo no es el método de implementación, sino la lógica de generación de resultados de inferencia.

En la IA tradicional, la inferencia es unidireccional, una entrada corresponde a una salida del modelo, y el sistema asume que esta salida es confiable. El problema es que esta confianza depende completamente del modelo en sí, sin restricciones externas. Lo primero que hace #opg es romper esa unicidad del camino.

La misma entrada no pasa solo por un modelo, sino que se distribuye a múltiples nodos de inferencia, y cada nodo puede generar resultados de manera independiente. Así, la salida ya no es única, sino que se genera un conjunto de resultados candidatos. Al principio pensé que esto solo mejoraba la robustez, pero al seguir investigando, me di cuenta de que la clave no está en la cantidad, sino en el siguiente paso, porque estos resultados candidatos no se devuelven directamente al usuario, sino que entran en una capa de validación.

La capa de validación no se encarga de calcular, sino de juzgar la consistencia. Es decir, el sistema ya no pregunta cuál modelo es correcto, sino cuáles resultados son estructuralmente consistentes. He estado reflexionando sobre esto durante mucho tiempo, y de repente me di cuenta de que realmente está cambiando la hipótesis básica de la IA; este paso es crucial porque, una vez que los resultados de inferencia deben pasar por la capa de validación para ser válidos, la salida de la IA ya no es un resultado generado, sino un resultado de consenso.

Siguiendo adelante y analizando la capa de gestión de modelos, también se da cuenta de que no es simplemente almacenar modelos; el modelo en sí es reemplazable/versionable, y cada llamada puede provenir de diferentes nodos. Todo el sistema se asemeja más a un flujo constante en lugar de una operación fija. Así, al combinar todo esto, la estructura de OpenGradient se vuelve muy clara: la capa de inferencia se encarga de generar diferencias, la capa de validación se encarga de digerir las diferencias, y la capa de gestión se encarga de mantener la reemplazabilidad del modelo.

Así que cuanto más lo pienso, más creo que lo que realmente está cambiando no son las capacidades de la IA, sino la naturaleza de los resultados de la IA. Antes, la salida de la IA era un punto; ahora, la salida de la IA se convierte en un estado verificado.

Si este mecanismo es válido, entonces $OPG no está haciendo que la IA sea más poderosa, sino que está transformando la IA de un sistema de decisión de modelo único a un sistema de consenso de múltiples nodos, y este cambio en sí es más fundamental que el tamaño del modelo.
·
--
Recientemente volví a revisar el whitepaper de @Bedrock , y hay un punto que me tiene pensando: su sistema parece no estar diseñado desde la "rentabilidad", sino desde "cómo entra el capital". Al principio pensé que el vault solo era una entrada para almacenar activos, pero a medida que profundizaba, me di cuenta de que no se parece a un lugar para guardar dinero, sino más bien a un divisor. Una vez que los activos entran, no van directamente a una estrategia de ganancia, sino que primero se dividen en dos partes: una parte va a la red de staking base o a la reinversión, y la otra se queda dentro del protocolo como un comprobante de liquidez. Esta estructura puede parecer un poco enrevesada al principio, pero si miras con atención, te das cuenta de que está haciendo que los activos entren al sistema en una sola forma. Todos los activos que entran a Bedrock serán redefinidos estructuralmente en la entrada. Al principio pensé que esto era para optimizar las ganancias, pero luego me di cuenta de que no es así, porque esta división ocurre antes de las ganancias, ni siquiera le importa si después te conectas a Babylon o a otra red. Lo que le importa es: una vez que este activo entra al sistema, debe tener simultáneamente dos estados, uno es el estado de participar en la red base, y el otro es permanecer en la capa de circulación. He estado pensando en este diseño durante mucho tiempo y de repente me di cuenta de que esto podría ser lo que hace a Bedrock diferente de muchos diseños de restaking. Muchos protocolos siguen la secuencia "activo entra → elige estrategia → genera ganancias". Pero Bedrock se parece más a "activo entra → primero se divide la estructura → luego se decide cómo usarlo". La entrada determina todas las posibilidades futuras. Si la entrada no se divide, todos los módulos posteriores deben diseñarse en torno a una única forma de activo, y el sistema se volverá cada vez más rígido. Pero si la entrada en sí misma es una capa de conversión estructural, entonces todas las redes de ganancias posteriores, redes de validación, y caminos de liquidez, en realidad solo están consumiendo esta estructura ya dividida. Así que al mirar de nuevo el vault, ya no es solo una entrada, sino el "generador de estructuras" de todo el sistema. Lo que decide no es a dónde va el activo, sino en qué se convertirá al entrar al sistema posterior. Si este mecanismo es válido, entonces el verdadero núcleo de Bedrock puede que no esté en esas redes de ganancias en el backend, sino en esta capa de entrada: transforma la acción de "activos ingresando al protocolo" en una reescritura estructural. #bedrock $BR
Recientemente volví a revisar el whitepaper de @Bedrock , y hay un punto que me tiene pensando: su sistema parece no estar diseñado desde la "rentabilidad", sino desde "cómo entra el capital".

Al principio pensé que el vault solo era una entrada para almacenar activos, pero a medida que profundizaba, me di cuenta de que no se parece a un lugar para guardar dinero, sino más bien a un divisor.

Una vez que los activos entran, no van directamente a una estrategia de ganancia, sino que primero se dividen en dos partes: una parte va a la red de staking base o a la reinversión, y la otra se queda dentro del protocolo como un comprobante de liquidez.

Esta estructura puede parecer un poco enrevesada al principio, pero si miras con atención, te das cuenta de que está haciendo que los activos entren al sistema en una sola forma.

Todos los activos que entran a Bedrock serán redefinidos estructuralmente en la entrada.

Al principio pensé que esto era para optimizar las ganancias, pero luego me di cuenta de que no es así, porque esta división ocurre antes de las ganancias, ni siquiera le importa si después te conectas a Babylon o a otra red.

Lo que le importa es: una vez que este activo entra al sistema, debe tener simultáneamente dos estados, uno es el estado de participar en la red base, y el otro es permanecer en la capa de circulación.

He estado pensando en este diseño durante mucho tiempo y de repente me di cuenta de que esto podría ser lo que hace a Bedrock diferente de muchos diseños de restaking.

Muchos protocolos siguen la secuencia "activo entra → elige estrategia → genera ganancias".

Pero Bedrock se parece más a "activo entra → primero se divide la estructura → luego se decide cómo usarlo".

La entrada determina todas las posibilidades futuras.

Si la entrada no se divide, todos los módulos posteriores deben diseñarse en torno a una única forma de activo, y el sistema se volverá cada vez más rígido.

Pero si la entrada en sí misma es una capa de conversión estructural, entonces todas las redes de ganancias posteriores, redes de validación, y caminos de liquidez, en realidad solo están consumiendo esta estructura ya dividida.

Así que al mirar de nuevo el vault, ya no es solo una entrada, sino el "generador de estructuras" de todo el sistema.

Lo que decide no es a dónde va el activo, sino en qué se convertirá al entrar al sistema posterior.

Si este mecanismo es válido, entonces el verdadero núcleo de Bedrock puede que no esté en esas redes de ganancias en el backend, sino en esta capa de entrada: transforma la acción de "activos ingresando al protocolo" en una reescritura estructural.
#bedrock $BR
·
--
Recientemente, mientras miraba @Bedrock , de repente me di cuenta de un problema que antes no había notado. Muchos protocolos, al expandirse, tienden a unificar el protocolo. Hoy conecto un protocolo. Mañana conecto otro protocolo. Pasado mañana conecto otro protocolo más. Al final, apiñan muchas funciones juntas. Pero Bedrock parece estar haciendo otra cosa. No le preocupa cómo se ve el protocolo. Le importa más en qué se convertirán los activos una vez que entren. Al principio, pensé que uniBTC, uniETH eran solo activos empaquetados, pero luego me di cuenta de que no es así. Porque lo más especial de Bedrock no es cuántos activos ha creado, sino que, sin importar qué activo entre, al final todos entran en la misma estructura. Esto en realidad es una elección bastante extraña. La lógica normal debería ser que los activos se adapten al protocolo. BTC tiene su propia forma de jugar. ETH tiene su propia forma de jugar. Diferentes activos corresponden a diferentes reglas. Pero Bedrock parece estar haciendo lo contrario. Primero define un conjunto de formas de activos y luego deja que diferentes activos entren en esa forma. He estado observando esto durante mucho tiempo y de repente me di cuenta de un problema. Muchos protocolos se vuelven cada vez más complejos a medida que crecen, porque cada vez que se añade un activo, se suma un conjunto de lógica. Pero Bedrock ha estado suprimiendo esa complejidad. No permite que el sistema cambie con los activos. Sino que hace que los activos se unifiquen una vez que entran en el sistema. La ventaja de esto no es que se expanda más rápido. Sino que, cuando se añadan nuevos activos en el futuro, el protocolo en sí no necesita cambiar mucho. Lo que cambia es la cantidad de activos. No la estructura del protocolo. Cuanto más lo pienso, más creo que esta podría ser una parte que a menudo se pasa por alto en Bedrock. Muchos protocolos están constantemente añadiendo funciones. Bedrock parece estar validando continuamente el mismo marco. Porque para ellos, lo más importante puede que no sea cuántos activos soportan. Sino que, sin importar qué activos entren, aún pueden mantener la misma lógica operativa. Si esto es cierto, la ventaja competitiva de Bedrock puede no provenir de un activo específico. Sino de esta estructura unificada que puede seguir acomodando nuevos activos. Así que, al mirar nuevamente uniBTC, uniETH, tal vez no sean el producto en sí mismo. Sino que se parecen más a una validación de si este marco de activos de Bedrock realmente puede seguir expandiéndose. #bedrock $BR
Recientemente, mientras miraba @Bedrock , de repente me di cuenta de un problema que antes no había notado.

Muchos protocolos, al expandirse, tienden a unificar el protocolo.

Hoy conecto un protocolo.

Mañana conecto otro protocolo.

Pasado mañana conecto otro protocolo más.

Al final, apiñan muchas funciones juntas.

Pero Bedrock parece estar haciendo otra cosa.

No le preocupa cómo se ve el protocolo.

Le importa más en qué se convertirán los activos una vez que entren.

Al principio, pensé que uniBTC, uniETH eran solo activos empaquetados, pero luego me di cuenta de que no es así.

Porque lo más especial de Bedrock no es cuántos activos ha creado, sino que, sin importar qué activo entre, al final todos entran en la misma estructura.

Esto en realidad es una elección bastante extraña.

La lógica normal debería ser que los activos se adapten al protocolo.

BTC tiene su propia forma de jugar.

ETH tiene su propia forma de jugar.

Diferentes activos corresponden a diferentes reglas.

Pero Bedrock parece estar haciendo lo contrario.

Primero define un conjunto de formas de activos y luego deja que diferentes activos entren en esa forma.

He estado observando esto durante mucho tiempo y de repente me di cuenta de un problema.

Muchos protocolos se vuelven cada vez más complejos a medida que crecen, porque cada vez que se añade un activo, se suma un conjunto de lógica.

Pero Bedrock ha estado suprimiendo esa complejidad.

No permite que el sistema cambie con los activos.

Sino que hace que los activos se unifiquen una vez que entran en el sistema.

La ventaja de esto no es que se expanda más rápido.

Sino que, cuando se añadan nuevos activos en el futuro, el protocolo en sí no necesita cambiar mucho.

Lo que cambia es la cantidad de activos.

No la estructura del protocolo.

Cuanto más lo pienso, más creo que esta podría ser una parte que a menudo se pasa por alto en Bedrock.

Muchos protocolos están constantemente añadiendo funciones.

Bedrock parece estar validando continuamente el mismo marco.

Porque para ellos, lo más importante puede que no sea cuántos activos soportan.

Sino que, sin importar qué activos entren, aún pueden mantener la misma lógica operativa.

Si esto es cierto, la ventaja competitiva de Bedrock puede no provenir de un activo específico.

Sino de esta estructura unificada que puede seguir acomodando nuevos activos.

Así que, al mirar nuevamente uniBTC, uniETH, tal vez no sean el producto en sí mismo.

Sino que se parecen más a una validación de si este marco de activos de Bedrock realmente puede seguir expandiéndose.
#bedrock $BR
·
--
¿Qué está pasando? ¿Ya se puede participar en nuevas ofertas de acciones de EE. UU. después de un tiempo sin mirar? Parece que no hay mucha gente en la nueva oferta de Spacex en Binance. La oportunidad es bastante buena, aunque no sé si las tarifas son muy altas.
¿Qué está pasando?
¿Ya se puede participar en nuevas ofertas de acciones de EE. UU. después de un tiempo sin mirar?
Parece que no hay mucha gente en la nueva oferta de Spacex en Binance.
La oportunidad es bastante buena, aunque no sé si las tarifas son muy altas.
·
--
Recientemente volví a revisar @Bedrock y de repente me di cuenta de algo que había estado ignorando. Muchos hablan de Bedrock, discutiendo sobre uniBTC, motores de rendimiento y reinversión. Pero luego me di cuenta de que si quitamos el PoR (Prueba de Reservas), muchos de los mecanismos posteriores pierden su razón de ser. Al principio, siempre vi el PoR como una prueba de seguridad. Prueba de que el BTC existe, prueba de que las reservas están bien. Luego me di cuenta de que esta comprensión era demasiado superficial. Porque el núcleo de Bedrock no es el BTC en sí, sino el uniBTC. Los usuarios depositan BTC, pero lo que realmente participa en los rendimientos, la liquidez y la reinversión es el uniBTC. Es decir, el sistema realmente está moviendo un comprobante que representa el BTC. En este punto, la cuestión cambia. Para Bedrock, lo más importante ya no es la tasa de rendimiento, sino si el uniBTC puede seguir siendo confiable. Porque el motor de rendimiento se basa en uniBTC. La reinversión se basa en uniBTC. La liquidez se basa en uniBTC. Estos mecanismos, aunque aparentemente independientes, en realidad dependen de un mismo supuesto: 1 uniBTC siempre corresponde a 1 BTC real. Y el PoR se encarga de probar esto. Así que cada vez estoy más convencido de que el PoR dentro de Bedrock no es simplemente una función auxiliar, sino el ancla de todo el sistema. Lo que Bedrock ha estado haciendo, en esencia, es expandir constantemente el uso de uniBTC. Pero cuanto más se expande su uso, más lejos están los activos del BTC original. En este punto, la capacidad más importante del protocolo ya no es generar más rendimientos, sino seguir demostrando que esta relación de mapeo no se ha roto. Porque una vez que esta capa de confianza desaparece, el problema no es solo la caída de los rendimientos, sino que toda la lógica de rendimiento perderá su fundamento al mismo tiempo. Así que ahora veo el PoR y ya no lo considero un módulo de seguridad. Es más como la base de toda la arquitectura de Bedrock. El motor de rendimiento puede existir porque el PoR está presente. El uniBTC puede expandirse porque el PoR está presente. La reinversión puede existir también porque el PoR está presente. Si decimos que el uniBTC es el nuevo empaquetado del BTC por parte de Bedrock, entonces el PoR es el encargado de asegurar que este empaquetado nunca se separe del activo real. Y esta puede ser la capa más fácil de ignorar de Bedrock, pero también la más central en su mecanismo. #bedrock $BR
Recientemente volví a revisar @Bedrock y de repente me di cuenta de algo que había estado ignorando.

Muchos hablan de Bedrock, discutiendo sobre uniBTC, motores de rendimiento y reinversión. Pero luego me di cuenta de que si quitamos el PoR (Prueba de Reservas), muchos de los mecanismos posteriores pierden su razón de ser.

Al principio, siempre vi el PoR como una prueba de seguridad. Prueba de que el BTC existe, prueba de que las reservas están bien. Luego me di cuenta de que esta comprensión era demasiado superficial.

Porque el núcleo de Bedrock no es el BTC en sí, sino el uniBTC.

Los usuarios depositan BTC, pero lo que realmente participa en los rendimientos, la liquidez y la reinversión es el uniBTC. Es decir, el sistema realmente está moviendo un comprobante que representa el BTC.

En este punto, la cuestión cambia.

Para Bedrock, lo más importante ya no es la tasa de rendimiento, sino si el uniBTC puede seguir siendo confiable.

Porque el motor de rendimiento se basa en uniBTC.

La reinversión se basa en uniBTC.

La liquidez se basa en uniBTC.

Estos mecanismos, aunque aparentemente independientes, en realidad dependen de un mismo supuesto:

1 uniBTC siempre corresponde a 1 BTC real.

Y el PoR se encarga de probar esto.

Así que cada vez estoy más convencido de que el PoR dentro de Bedrock no es simplemente una función auxiliar, sino el ancla de todo el sistema.

Lo que Bedrock ha estado haciendo, en esencia, es expandir constantemente el uso de uniBTC. Pero cuanto más se expande su uso, más lejos están los activos del BTC original. En este punto, la capacidad más importante del protocolo ya no es generar más rendimientos, sino seguir demostrando que esta relación de mapeo no se ha roto.

Porque una vez que esta capa de confianza desaparece, el problema no es solo la caída de los rendimientos, sino que toda la lógica de rendimiento perderá su fundamento al mismo tiempo.

Así que ahora veo el PoR y ya no lo considero un módulo de seguridad.

Es más como la base de toda la arquitectura de Bedrock.

El motor de rendimiento puede existir porque el PoR está presente.

El uniBTC puede expandirse porque el PoR está presente.

La reinversión puede existir también porque el PoR está presente.

Si decimos que el uniBTC es el nuevo empaquetado del BTC por parte de Bedrock, entonces el PoR es el encargado de asegurar que este empaquetado nunca se separe del activo real.

Y esta puede ser la capa más fácil de ignorar de Bedrock, pero también la más central en su mecanismo.
#bedrock $BR
·
--
Recientemente volví a revisar @GeniusOfficial las Órdenes Fantasma y de repente me di cuenta de un problema que había estado ignorando. Mucha gente habla de Genius y le gusta comentar sobre el Agente de IA, pero me di cuenta de que si eliminamos las Órdenes Fantasma, en realidad es muy difícil para el Agente participar en las operaciones. Porque el mayor problema del Agente nunca ha sido si puede o no analizar el mercado, sino si hay algo que pueda gestionar. En el pasado, las operaciones en la cadena ocurrían en tiempo real, y una vez que una operación entraba al mercado, lo que sucedía después ya estaba prácticamente determinado. En ese entorno, el Agente se asemeja más a una herramienta de análisis, ya que no tiene suficiente tiempo y espacio para participar en la toma de decisiones. Las Órdenes Fantasma cambian precisamente eso. En Genius, las órdenes no ingresan al mercado de inmediato, sino que primero permanecen en el sistema, convirtiéndose en Órdenes Fantasma. Mucha gente las entiende como órdenes ocultas, pero cada vez pienso más que lo oculto es solo el resultado, no el objetivo. Lo realmente importante es que las Órdenes Fantasma permiten que las operaciones tengan por primera vez un "estado de espera". La orden ya existe, pero aún no se ejecuta. La intención ya ha surgido, pero aún no ha ingresado al mercado. En este momento, el Agente realmente tiene un objeto de operación. Puede juzgar si ejecutar, puede elegir el momento de ejecución, puede elegir la ruta de ejecución, e incluso puede optar por no ejecutar temporalmente. Porque ya no se enfrenta a una operación que ya ha ocurrido, sino a una operación que está esperando ser procesada. Cuanto más pensaba en ello, más me daba cuenta de que las Órdenes Fantasma y el Agente en realidad no son dos funciones independientes. Son más como dos capas en una misma estructura. Las Órdenes Fantasma son responsables de capturar la intención. El Agente es responsable de gestionar la intención. Si no hay Órdenes Fantasma, el Agente al final solo puede hacer análisis, y de la misma manera, las Órdenes Fantasma serían solo un montón de órdenes esperando a ser ejecutadas. Por eso, muchos piensan que el Agente es una capacidad recién añadida detrás de Genius, yo más bien creo que las Órdenes Fantasma son la premisa. Primero transforman la operación de un comportamiento instantáneo a un objeto gestionable, y luego el Agente tiene la oportunidad de participar en las decisiones y ejecuciones posteriores. Así que cada vez estoy más convencido de que el valor más importante de las Órdenes Fantasma no es ocultar órdenes, sino que crea un nuevo estado de operación dentro de toda la arquitectura de Genius, esperando ser gestionado. Este paso puede parecer insignificante, pero podría ser la base real para que el Agente pueda entrar en el flujo de operaciones. #genius $GENIUS
Recientemente volví a revisar @GeniusOfficial las Órdenes Fantasma y de repente me di cuenta de un problema que había estado ignorando.

Mucha gente habla de Genius y le gusta comentar sobre el Agente de IA, pero me di cuenta de que si eliminamos las Órdenes Fantasma, en realidad es muy difícil para el Agente participar en las operaciones.

Porque el mayor problema del Agente nunca ha sido si puede o no analizar el mercado, sino si hay algo que pueda gestionar.

En el pasado, las operaciones en la cadena ocurrían en tiempo real, y una vez que una operación entraba al mercado, lo que sucedía después ya estaba prácticamente determinado. En ese entorno, el Agente se asemeja más a una herramienta de análisis, ya que no tiene suficiente tiempo y espacio para participar en la toma de decisiones.

Las Órdenes Fantasma cambian precisamente eso.

En Genius, las órdenes no ingresan al mercado de inmediato, sino que primero permanecen en el sistema, convirtiéndose en Órdenes Fantasma. Mucha gente las entiende como órdenes ocultas, pero cada vez pienso más que lo oculto es solo el resultado, no el objetivo.

Lo realmente importante es que las Órdenes Fantasma permiten que las operaciones tengan por primera vez un "estado de espera".

La orden ya existe, pero aún no se ejecuta.

La intención ya ha surgido, pero aún no ha ingresado al mercado.

En este momento, el Agente realmente tiene un objeto de operación.

Puede juzgar si ejecutar, puede elegir el momento de ejecución, puede elegir la ruta de ejecución, e incluso puede optar por no ejecutar temporalmente. Porque ya no se enfrenta a una operación que ya ha ocurrido, sino a una operación que está esperando ser procesada.

Cuanto más pensaba en ello, más me daba cuenta de que las Órdenes Fantasma y el Agente en realidad no son dos funciones independientes.

Son más como dos capas en una misma estructura.

Las Órdenes Fantasma son responsables de capturar la intención.

El Agente es responsable de gestionar la intención.

Si no hay Órdenes Fantasma, el Agente al final solo puede hacer análisis, y de la misma manera, las Órdenes Fantasma serían solo un montón de órdenes esperando a ser ejecutadas.

Por eso, muchos piensan que el Agente es una capacidad recién añadida detrás de Genius, yo más bien creo que las Órdenes Fantasma son la premisa. Primero transforman la operación de un comportamiento instantáneo a un objeto gestionable, y luego el Agente tiene la oportunidad de participar en las decisiones y ejecuciones posteriores.

Así que cada vez estoy más convencido de que el valor más importante de las Órdenes Fantasma no es ocultar órdenes, sino que crea un nuevo estado de operación dentro de toda la arquitectura de Genius, esperando ser gestionado.

Este paso puede parecer insignificante, pero podría ser la base real para que el Agente pueda entrar en el flujo de operaciones.
#genius $GENIUS
·
--
Verificado
Recientemente volví a revisar @GeniusOfficial de las Órdenes Fantasma, y de repente me di cuenta de que mucha gente puede haberlo entendido mal. Todos piensan que la función de las Órdenes Fantasma es ocultar órdenes, prevenir el front-running y evitar exponer la intención de trading. Pero luego me di cuenta de que, si solo fuera para ocultar órdenes, Genius no tendría necesidad de ponerlo al frente de todo el sistema. Porque lo verdaderamente importante de las Órdenes Fantasma no es ocultar, sino controlar las órdenes. En el pasado, los usuarios en la cadena generaban ideas de trading, y las órdenes entraban directamente al mercado, donde la liquidez, el descubrimiento de precios y la ejecución se organizaban alrededor del mercado. Pero #genius es diferente. Las órdenes no entran al mercado de inmediato, sino que primero se convierten en Órdenes Fantasma, permaneciendo en el sistema, y luego se entregan a la Capa de Trading Unificada, la capa de ejecución y la capa de enrutamiento para su procesamiento. Al principio, no entendía por qué había que agregar esta capa. Luego de repente me di cuenta de que, sin las Órdenes Fantasma, muchos mecanismos detrás de $GENIUS en realidad perderían su significado. Porque para que el enrutamiento unificado decida cómo ejecutar, primero debe recibir la orden. Para que la ejecución cross-chain decida qué cadena usar, primero debe recibir la orden. El Agente de IA también debe recibir la orden para participar en la toma de decisiones. Si la orden entra al mercado desde el principio, el control de la orden en realidad ya pertenece al mercado. Así que lo que realmente cambia con las Órdenes Fantasma no es si la orden es pública o no. Sino a quién pertenece la orden primero. Antes, el mercado obtenía la orden primero y luego organizaba la liquidez. Ahora, Genius obtiene la orden primero y luego decide cómo organizar el mercado. Estos dos órdenes pueden parecer similares, pero en realidad no son lo mismo. Porque la orden es el punto de partida de toda actividad de trading. Quien obtenga la orden primero, tiene el derecho de programación posterior. Así que cada vez creo más que las Órdenes Fantasma en Genius no son una función de trading, sino la entrada a todo el sistema. Si este mecanismo se establece, Genius no solo obtendrá capacidad de ejecución, sino también la capacidad de organizar todo el proceso de trading. Pero si las Órdenes Fantasma no tienen valor, y las órdenes vuelven a entrar directamente al mercado, entonces la Capa de Trading Unificada, la ejecución unificada y muchas de las estructuras posteriores finalmente se degradarán a simples agregadores. Así que ahora lo que más me interesa ya no es si las Órdenes Fantasma pueden ocultar órdenes. Sino si validan si las órdenes futuras deberían pertenecer primero al mercado o al sistema.
Recientemente volví a revisar @GeniusOfficial de las Órdenes Fantasma, y de repente me di cuenta de que mucha gente puede haberlo entendido mal.

Todos piensan que la función de las Órdenes Fantasma es ocultar órdenes, prevenir el front-running y evitar exponer la intención de trading.

Pero luego me di cuenta de que, si solo fuera para ocultar órdenes, Genius no tendría necesidad de ponerlo al frente de todo el sistema.

Porque lo verdaderamente importante de las Órdenes Fantasma no es ocultar, sino controlar las órdenes.

En el pasado, los usuarios en la cadena generaban ideas de trading, y las órdenes entraban directamente al mercado, donde la liquidez, el descubrimiento de precios y la ejecución se organizaban alrededor del mercado.

Pero #genius es diferente.

Las órdenes no entran al mercado de inmediato, sino que primero se convierten en Órdenes Fantasma, permaneciendo en el sistema, y luego se entregan a la Capa de Trading Unificada, la capa de ejecución y la capa de enrutamiento para su procesamiento.

Al principio, no entendía por qué había que agregar esta capa.

Luego de repente me di cuenta de que, sin las Órdenes Fantasma, muchos mecanismos detrás de $GENIUS en realidad perderían su significado.

Porque para que el enrutamiento unificado decida cómo ejecutar, primero debe recibir la orden.

Para que la ejecución cross-chain decida qué cadena usar, primero debe recibir la orden.

El Agente de IA también debe recibir la orden para participar en la toma de decisiones.

Si la orden entra al mercado desde el principio, el control de la orden en realidad ya pertenece al mercado.

Así que lo que realmente cambia con las Órdenes Fantasma no es si la orden es pública o no.

Sino a quién pertenece la orden primero.

Antes, el mercado obtenía la orden primero y luego organizaba la liquidez.

Ahora, Genius obtiene la orden primero y luego decide cómo organizar el mercado.

Estos dos órdenes pueden parecer similares, pero en realidad no son lo mismo.

Porque la orden es el punto de partida de toda actividad de trading.

Quien obtenga la orden primero, tiene el derecho de programación posterior.

Así que cada vez creo más que las Órdenes Fantasma en Genius no son una función de trading, sino la entrada a todo el sistema.

Si este mecanismo se establece, Genius no solo obtendrá capacidad de ejecución, sino también la capacidad de organizar todo el proceso de trading.

Pero si las Órdenes Fantasma no tienen valor, y las órdenes vuelven a entrar directamente al mercado, entonces la Capa de Trading Unificada, la ejecución unificada y muchas de las estructuras posteriores finalmente se degradarán a simples agregadores.

Así que ahora lo que más me interesa ya no es si las Órdenes Fantasma pueden ocultar órdenes.

Sino si validan si las órdenes futuras deberían pertenecer primero al mercado o al sistema.
Inicia sesión para explorar más contenidos
Únete a usuarios globales de criptomonedas en Binance Square
⚡️ Obtén información útil y actualizada sobre criptos.
💬 Avalado por el mayor exchange de criptomonedas en el mundo.
👍 Descubre perspectivas reales de creadores verificados.
Email/número de teléfono
Mapa del sitio
Preferencias de cookies
Términos y condiciones de la plataforma