昨天不是刚亏吗 今天怎么又亏

前两篇我在一台云服务器上测了 Rayls 的证明代码，但数字只来自一种机器，测试代码也没放在读者能直接复现的地方。这次我把测试代码公开到 GitHub，让 GitHub 自己的服务器替我跑，换了三种 CPU，日志谁都能点开看。
先给短答案。以 Rayls Enygma 隐私转账电路的 6 人匿名集为例，一笔转账的零知识证明只用 1 个 vCPU 时要 1.55 到 1.95 秒，在 4 个 vCPU 上要 0.63 到 0.71 秒，验证这个证明只要 1 毫秒左右。服务第一次处理某一档转账时，还要额外花 1.9 到 2.9 秒把证明密钥读进内存。按串行处理请求算，一台 4 vCPU 的云服务器每秒能出 1.4 到 1.6 个证明。
下面讲这些数字是怎么来的、在哪里能复现，以及它们对一家机构要准备多少机器意味着什么。
隐私转账为什么要"算"
零知识证明可以理解成一张数学凭证：付款方不公开余额、金额和对手方，也能向网络证明这笔账是对的。代价在生成这张凭证上。Rayls 的 Enygma 用的是 Groth16 证明系统，它的特点是证明很小、验证很快，生成却要做大量椭圆曲线运算。所以"隐私要多少算力"这个问题，实际问的是生成证明要多久。
这里的 k 是匿名集大小。一笔转账会给 k 个参与方各生成一个金额承诺，真正的收款方藏在其中，旁人看不出是谁付给了谁。k 越大藏得越深，电路也越大。Rayls 仓库自带的压力测试脚本用的是 k=6，所以下文主要看 k=6。
这些结论不只适用于 Rayls。凡是用 Groth16 做隐私转账的系统，成本都落在同样的环节上，只是电路规模不同。
怎么测的，任何人都能复现
被测的是 Rayls 开源的证明服务 rayls-sovereign-gnark-api，提交 67c4c26。电路和证明代码一行没改。我的测试代码放在公开仓库 hansonhan0520-lang/enygma-bench，脚本会自动拉取这个提交，把测试文件放进它的电路目录，调用仓库自己的证明函数。
测试代码放进仓库后，由 GitHub 自己的云服务器（GitHub Actions）运行。每次运行的完整日志都自动提交到仓库的 results 文件夹，读者点 Actions 页面的 Run workflow 就能在自己的账号下再跑一遍。GitHub 文档写明，公开仓库的标准 Linux 运行器是 4 个 CPU、16 GB 内存，分 x64 和 arm64 两种。
本文用到三台机器，每台的 CPU 拓扑都由日志里的 lscpu 记录：
GitHub x64 运行器，Intel Xeon Platinum 8573C，4 个 vCPU，实为 2 个物理核、每核 2 个线程。
GitHub arm64 运行器，ARM Neoverse-N2，4 个 vCPU，4 个物理核、每核 1 个线程。
我自己的云端环境，Intel Xeon 2.1GHz，2 个物理核。
每台机器上，k=2 到 6 每一档先生成一个证明并用验证密钥验过，再连续计时 20 次取中位数，分别把可用的 vCPU 限定为 1 个、2 个、4 个各测一遍，我那台只有 2 个。GitHub 两台的数字来自 Actions 运行 37741247183，第三台来自同一天的本地运行，全文的数字和两张图都从同一份数据文件生成。
哪些是新的，这里说清楚。k=3 到 5 的测试数据沿用我上一篇写的生成器，它先逐字段复现了 Rayls 官方发布的 k=2 和 k=6 两组数据才被采用，这次没有改。这篇新增的是：公开可复现的测试仓库，两种新 CPU 上的 4 vCPU 测量，以及密钥加载时间的单独计时。
换 CPU 差多少
k=6 只用 1 个 vCPU 时的证明时间，Intel 8573C 是 1.55 秒，Neoverse-N2 是 1.81 秒，我那台 2.1GHz Xeon 是 1.95 秒，最慢的比最快的多 26%。用满全部 vCPU 后，两台 GitHub 机器分别是 0.71 秒和 0.63 秒，我那台用满 2 个 vCPU 是 1.37 秒。
验证时间在三台机器上都在 1 毫秒左右，从 0.98 到 1.28 毫秒。证明本身固定 164 字节，随证明一起传递的公开数据在 k=6 时是 1,612 字节，三台机器完全一致。
多核能快多少，取决于是不是真的核
这是这次最意外的结果。从 1 个 vCPU 到 2 个，两台 GitHub 机器都快了 1.88 到 1.89 倍，接近翻倍。但从 2 个到 4 个，两台分道扬镳：Neoverse-N2 又快了 1.51 倍，Intel 8573C 只快了 1.17 倍。
两台机器的差别在 lscpu 里写得很清楚。Neoverse-N2 的 4 个 vCPU 是 4 个物理核，Intel 8573C 的 4 个 vCPU 是 2 个物理核各跑 2 个线程。所以在 Intel 这台上，"从 2 个 vCPU 到 4 个"其实没有增加物理核，只是让每个核多跑一个线程。加速比和物理核数对得上，这是我从拓扑记录推出的解释，不同 CPU 的缓存和频率差异没有单独拆开。
同一个 x64 运行器标签，两次运行分到的硬件也不一样。同一天早些时候的一次运行分到的是 AMD EPYC 9V45，从 2 个 vCPU 到 4 个同样只快了 1.18 倍，但那次没记录拓扑，所以我不把它算作证据。读者自己复现时，x64 那台可能分到别的 CPU，看日志开头的 lscpu 就知道是哪种。
这条也修正了我自己。上一篇在我的云端环境测到 2 个 vCPU 平均只快 1.64 倍，当时没有说明这可能只是那台机器的情况。这次同一环境下 k=6 只快 1.43 倍，而两台 GitHub 机器接近 1.9 倍。所以"翻倍资源快不到两倍"更像是那台云端机器的特点，在另外两种 CPU 上并不成立。
第 6 个参与者的台阶，换了 CPU 还在
上一篇在单台机器上测到，k=5 到 k=6 这一步比前面每一步贵得多。这次三台机器都复现了。只用 1 个 vCPU 时，k=2 到 5 之间每加一个参与者平均多花 114 到 143 毫秒，而 k=5 到 6 这一步要多花 451 到 619 毫秒，是前面平均值的 3.5 到 5.0 倍。
原因和上一篇一样：约束数每多一个参与者固定增加 8,112 条，但证明系统按 2 的幂次分配计算空间，k=2 到 5 都在 65,536 以内，k=6 越过了这条线，计算空间变成 131,072。三台机器、两种指令集上，这个计算空间的数值完全相同，这次多出来的信息是：台阶出在电路本身，和 CPU 无关。
冷启动慢在哪
上一篇我测到服务第一次处理某一档请求要多花 2.5 到 4.5 秒，并把原因归到加载证明密钥上，但没有单独测量。评审指出了这一点。
这次我单独计时了服务首次请求时调用的两个加载函数，一个读约束系统，一个读证明密钥，和服务代码 handler.go 里用的是同一组函数。k=6 时，读证明密钥在三台机器上要 1.94 到 2.94 秒，读约束系统只要 0.05 到 0.08 秒。
把加载时间加上一次热请求的耗时，和实测的冷请求相比，两台 GitHub 机器相差 22 毫秒和 12 毫秒，我那台相差 0.2 秒。所以冷启动基本就是读证明密钥的时间。对部署的意义很直接：服务启动时预先加载五档密钥，或者先发一轮预热请求，第一笔真实交易就不会多等这 2 到 3 秒。
一家机构要准备几台机器
这一节是推算，不是测量。按串行处理请求，一台 4 vCPU 机器在 k=6 下每秒能出 1.41 个（Intel 8573C）到 1.58 个（Neoverse-N2）证明。
英国 CHAPS 在 2025 财年平均每天处理 210,483 笔，结算时间是每个工作日 06:00 到 18:00，摊到 12 小时里约每秒 4.87 笔，需要 3.1 到 3.4 台这样的机器。英格兰银行 2021 年 12 月的 RTGS 与 CHAPS 介绍里记载的单日纪录，是 2018 年 3 月 29 日的 320,034 笔，按同样窗口约每秒 7.41 笔，需要 4.7 到 5.3 台。美国 Fedwire 2025 年平均每天 869,187 笔，按每天 22 小时的运行时间约每秒 10.97 笔，需要 6.9 到 7.8 台。
这些数字只是证明生成算力的一阶估算，不是 Rayls 的结算吞吐量。它们没有计入日内高峰、网络和账本的开销，也没有测试同一台机器上多个证明并行跑的情况。另外，证明由发起转账的机构各自生成，负载分散在各家机构，而不是集中在一台服务器上。
还没定的部分
这次只测了转账电路，存款、取款和 DvP 电路没有测。密钥是用仓库自己的 groth16.Setup 在本地生成的，Rayls 仓库的说明也写明，仓库里那套密钥同样是单方生成的开发测试产物，生产部署需要另做多方可信设置；证明时间取决于电路结构，和密钥的具体数值无关。Rayls 生产环境用的是什么硬件、匿名集大小设为多少，公开资料里我没有找到，所以上面的机器数只能说明量级。
我的看法
一笔零知识隐私转账的算力账，量级其实不大：1 个 vCPU 两秒以内，4 个 vCPU 不到一秒，验证的开销几乎可以忽略。真正要留意的有两处。一是匿名集大小越过 2 的幂次那一档时，成本会突然跳一截。二是第一次请求要先读两三秒的密钥。
判断标准也很简单：任何人都可以打开 enygma-bench 仓库的 Actions 页面再跑一遍，看自己拿到的 CPU 上数字是否落在同样的范围。如果 Rayls 将来公布生产环境的证明硬件，就可以直接拿这套测试去对照。
参考来源：
Rayls 证明服务源码，raylsnetwork/rayls-sovereign-gnark-api，提交 67c4c26（2026 年 8 月 20 日）：https://github.com/raylsnetwork/rayls-sovereign-gnark-api/commit/67c4c26696016b48e70950e284ae1a51b7d0cf0e
本文测试代码与全部日志，Actions 运行 37741247183（2026 年 10 月 8 日）：https://github.com/hansonhan0520-lang/enygma-bench
GitHub 托管运行器规格（2026 年 10 月 8 日查阅）：https://docs.github.com/en/actions/reference/runners/github-hosted-runners
Fedwire Funds 2025 年统计（页面更新于 2026 年 1 月 26 日）：https://www.frbservices.org/resources/financial-services/wires/volume-value-stats/annual-stats.html
英格兰银行支付与结算统计，CHAPS 2025 财年日均笔数：https://www.bankofengland.co.uk/payment-and-settlement/payment-and-settlement-statistics
英格兰银行《RTGS 与 CHAPS 简介》（2021 年 12 月），CHAPS 单日纪录：https://www.bankofengland.co.uk/-/media/boe/files/payments/rtgs-chaps-brief-intro.pdf
#RLS #零知识证明 $RLS

En el post anterior ejecuté el código de prueba que Rayls hizo público y medí que el conjunto anónimo de 6 personas tarda 1,96 segundos por registro. Pero en ese artículo había tres frases que eran inferencias y no mediciones; yo lo tengo claro. Esta semana cambié la máquina por una de 2 núcleos y añadí algunos datos más, así que ahora voy a completar esas tres frases con números.
Primero, aclaremos la relación entre este artículo y el anterior, para que los lectores no crean que es una re-publicación del mismo. El artículo anterior medía el tiempo de la prueba en un entorno de un solo núcleo para los modos de 2 personas y de 6 personas; esos dos números se volvieron a medir esta vez y casi no cambiaron. Todo el contenido nuevo de este artículo son esas tres cosas que en el artículo anterior no se pudieron medir y solo se pudieron inferir.

En la tabla comparativa de proveedores del sitio oficial de Rayls hay nueve filas, y elegí la de «Privacidad». La razón es muy simple: la privacidad es importante y Besu es de código abierto; puedo consultar su documentación y su código.
En la tabla comparativa, Rayls marca las dos filas: «Privacidad aislada» y «Privacidad criptográfica». Besu solo marca la primera. Planeo verificarlo con la documentación de la otra parte, así que consulté la documentación de Besu y, después, descargué su código y lo conté una vez.
La conclusión no es «Besu no sirve». La verdadera diferencia es esta: estas dos compañías ponen la privacidad en niveles distintos, y el momento en que Besu la trasladó fue más temprano que lo que mucha gente cree.

El 19 de septiembre, Rayls publicó un artículo (Privacy has a price). En el título decía honest math, pero todo el texto solo ofrecía un rango numérico: que una prueba requiere desde unos cientos de milisegundos hasta unos segundos. Durante varias semanas seguidas estuve escribiendo sobre la arquitectura de privacidad de Rayls; esta vez comparto contenido nuevo con ustedes. Descargué el código de las pruebas que hizo público, lo ejecuté decenas de veces y les comparto esta conclusión interesante.
Primero, hablemos de qué trató el blog. Su argumento central se puede resumir en dos frases. La primera es dónde está el costo: las transacciones confidenciales son más caras que las transparentes; lo caro está en generar las pruebas de conocimiento cero, mientras que verificar resulta más barato. Una prueba para un traspaso confidencial básico, en hardware comercial común, tarda de cientos de milisegundos a unos segundos. La segunda frase es qué deberíamos preguntar: las instituciones no deberían enfocarse solo en el TPS, sino en cuál es el rendimiento cuando se consideran la privacidad y el nivel de auditoría que realmente necesitan, además de la carga de trabajo de negocio real. El blog sostiene que el volumen de las liquidaciones entre instituciones no es grande y que está completamente dentro de la capacidad de los sistemas de liquidación confidencial.

Yo empecé a apostar RLS desde la fase de promesa previa; leer los materiales oficiales se volvió una costumbre. Después de que apareció el nombre “Sovereign”, la mayor parte de las discusiones se quedó en “¿solo cambiaron el nombre?”. Creo que esa pregunta está al revés. El nombre no importa; lo importante es qué se cambió debajo y cuántas cosas que uno puede verificar por sí mismo puede obtener una institución cuando hace la debida diligencia. En este artículo, cada uno de los números que aparecen tiene una fuente exacta que te di; puedes reproducirlo paso a paso siguiendo lo mismo.
Primero, aclaro una cosa: como la semana pasada escribí un artículo sobre la auditabilidad, algunos lectores pueden haberlo visto.
La mayor parte de este texto es nueva: proviene del repositorio de código de Axyl, del directorio de auditoría dentro del repositorio y del documento de la página de puntos de referencia de rendimiento de Axyl. Antes, yo no había tocado ninguno de esos tres lugares. Solo la pequeña sección sobre custodia de claves continúa las conclusiones del artículo anterior; la marcaré allí. Separo lo nuevo y lo anterior porque debería permitir que el lector distinga por sí mismo entre “lo que encontré esta semana” y “lo que ya había revisado antes”.

Empecé a hacer staking de RLS desde la fase de compromiso previo; leer el blog oficial se ha vuelto una costumbre. El 12 de septiembre, este artículo sobre la auditabilidad: en la segunda mitad enumera seis criterios y dice que, mediante la construcción, se satisfacen completamente. Estoy de acuerdo con esa idea, pero "cumplir mediante la construcción" es una afirmación que se puede verificar, no algo que uno tenga que creer a ciegas. Por eso dediqué una semana: tomé una por una esas seis condiciones, las busqué en el código fuente público, en la documentación técnica y en las interfaces on-chain, para encontrar correspondencias; ahora lo comparto con todos.
Primero, hablemos de su clasificación. Creo que es útil, y va más allá de la mayoría de los debates de "privacidad versus transparencia". Para la auditabilidad, hay tres vías: exigencia matemática, donde se incorpora en la construcción criptográfica; confianza en el hardware, apoyada en la integridad de un entorno de ejecución confiable; y control de acceso por políticas, donde quién puede ver qué lo determina la configuración del operador de la red.

Yo empecé a hacer staking de RLS desde la fase de precompromiso; normalmente leo el blog oficial, en gran parte para saber si mi posición se verá afectada. Este artículo del 30 de agosto sobre lo cuántico es diferente: a lo largo de todo el texto enseña a las instituciones cómo hacer adquisiciones, y no tiene una relación directa conmigo, un pequeño inversor como soy. Aun así, lo leí completo, porque al principio establecía una regla bastante tajante, y esa regla luego me llevó de vuelta al propio artículo.
La regla es así: una afirmación de “seguridad cuántica”, si no especifica claramente qué algoritmo estandarizado se usa y en qué nivel de parámetro, entonces no es una propuesta; es solo una etiqueta.

En el artículo anterior escribí por qué los bancos no quieren compartir un solo libro contable con sus competidores. Después de terminarlo, me surgió una duda: si cada entidad se queda con su propio libro contable, entonces ¿cómo se completa realmente una transacción entre dos bancos? El dinero y los activos se registran en dos libros distintos e incomunicados; suena a que no podría hacerse. Este texto busca explicar con claridad el proceso concreto.
Enlace del artículo anterior aquí: 《为什么银行不愿意和友商共用一个账本》
Primero fijemos el escenario; si no, la explicación quedaría demasiado vaga.
Supongamos que, dentro de la misma jurisdicción, hay dos bancos. El banco A necesita pagar usando depósitos tokenizados emitidos por él mismo. El banco B debe entregar un activo tokenizado. Ambas partes no quieren entregar a la otra información del cliente, saldos y lógica del negocio, ni tampoco desean que lo gestione cualquier tercero en custodia. Esta es la transacción más típica de pago contra entrega de valores (DvP), es decir, lo que en la industria se denomina DvP.

Cuando se habla de proyectos de blockchain para que los adopten las instituciones, normalmente se habla de “nuestra tecnología es más avanzada”. En esta ocasión, el artículo que Rayls publicó es distinto: dedica gran parte del texto a las quejas de los clientes, y el contenido de las quejas es bastante poco diplomático. Al terminar de leerlo, me di cuenta de que lo que realmente vale la pena destacar no es la lista de productos, sino que reconoce algo que la industria no suele estar dispuesta a admitir.
Primero, hablemos de un detalle anómalo que tiene este lanzamiento en sí.
Rayls lanzó Sovereign el 25 de agosto: una cadena privada para instituciones financieras. Pero según lo que afirma oficialmente, la plataforma subyacente lleva funcionando en entornos de producción desde junio de 2024; ya la han instalado y están usándola más de 30 instituciones financieras. Sovereign es una versión reconstruida del producto anterior, llamado Rayls Privacy Node; la reestructuración fue lo bastante profunda como para cambiarle el nombre.

Las noticias regulatorias normalmente las miro de reojo y sigo adelante, porque en su mayoría no tienen mucho que ver con los titulares comunes. Esta vez, con estas normas del Reino Unido, las leí y cambié de opinión, porque tiene un mecanismo que no es muy evidente y que en la práctica influirá en qué cadena elegirán las instituciones en el futuro.
Primero aclaremos la línea temporal, porque eso determina el nivel de urgencia.
El Parlamento del Reino Unido aprobó la normativa correspondiente el 4 de febrero de 2026. La FCA publicó el contenido central de este sistema el 30 de junio, en total cinco documentos de políticas. El canal de autorización se abrirá el 30 de septiembre, y el alcance completo de las actividades reguladas solo entrará en vigor de forma plena hasta el 25 de octubre de 2027.

En el artículo anterior hablé de la apertura del staking en sí. Pero en el backstage, muchos hermanos me preguntaban lo mismo una y otra vez: ¿cómo se hace exactamente? Así que esta vez recorrí todo el proceso de principio a fin, anoté cada paso y también todos los lugares donde es más fácil quedarse atascado. Solo tienes que seguirlo tal cual.
El enlace del artículo anterior está aquí:质押开放给所有人了,但有几件事最好先知道
Primero, aclaremos para quién está escrita esta guía. Si no has tenido ningún contacto con Rayls, e incluso no te suenan bien palabras como “billetera” y “puente”, entonces este artículo es para ti. Cada vez que aparezca algún término profesional, te lo explicaré rápidamente.

Empecé a hacer staking desde el lote de compromisos previos de junio, así que ya pasé una vez por este proceso. Esta vez se abrió para todo el mundo. Hay bastante gente a mi alrededor preguntándome cómo operar y qué tener en cuenta, así que lo escribo todo de una vez, claro y completo.
Primero, hablemos de los cambios en sí.
Rayls usa prueba de participación delegada: los validadores ejecutan nodos, producen bloques y garantizan la seguridad de la cadena pública. Los tenedores comunes no necesitan ejecutar sus propios nodos; pueden delegar su RLS a algún validador y compartir una parte de las recompensas del staking.
Este mecanismo se puso en marcha en junio, pero entonces solo estaba disponible para las carteras que participaron en el plan de compromisos previos y en las actividades de semillas de liquidez. Ese grupo ya bloqueó sus monedas antes de la red principal; la parte oficial les dio una bonificación anualizada del 55% durante tres meses, e incluso les envió 1 USDr a cada cartera que cumpliera las condiciones, para que ni siquiera tuvieran que preocuparse por no tener gas.

La mayoría de los proyectos habla de mecanismos de quema: de cuánto vamos a quemar. Lo que más me intriga es la parte del origen aguas arriba: de dónde provienen originalmente esos tokens que se queman. La respuesta al diseño de Rayls me sorprendió un poco; su punto de partida resulta ser un pago en moneda fiduciaria.
Primero, la conclusión. El punto de partida de toda la cadena no es el mundo de las criptomonedas, sino un pago en moneda fiduciaria que una institución emite en su propio país.
Una institución que realiza operaciones en Rayls a través de nodos de privacidad genera comisiones. El diseño clave es que pueden liquidar directamente con moneda fiduciaria o bien elegir usar USDr o RLS.

Cuando veo anuncios de bloqueos, normalmente solo me importa una cosa: si esta promesa puede verificarse. La mayoría de los proyectos que hablan de “bloqueo del equipo” terminan en una sola frase: solo puedes elegir creer o no creer. Esta vez no es igual, así que lo revisé en la cadena.
Primero, aclaremos los hechos. Parfin es el socio tecnológico central detrás de Rayls; se encarga del desarrollo de los nodos de privacidad, la red privada, el marco de privacidad Enygma y la cadena pública Rayls. Como compensación por el trabajo realizado antes del TGE, obtuvo 1,070,493,535 RLS, aproximadamente el 11% de la oferta total inicial de 10 mil millones de unidades.
Estos tokens se mantuvieron anteriormente en una entidad custodio en Ethereum. La razón es bastante práctica: durante el TGE, la cadena pública Rayls aún no estaba en marcha, así que solo podían custodiarse. Ahora que la cadena pública ya está disponible, estos tokens se han migrado a la cadena pública Rayls, se han bloqueado en un contrato inteligente verificable públicamente y, al mismo tiempo, el tiempo de desbloqueo se ha pospuesto de diciembre de 2026 a diciembre de 2027.

En el artículo sobre XP que escribí la vez pasada, siempre tuve curiosidad por una pregunta: cuando una stablecoin de tipo institucional como USDXP se emite, ¿cómo exactamente participa en una liquidación real transfronteriza? Este texto viene a completar esa duda, y de paso también me hizo entender por primera vez una expresión: “sándwich de stablecoins”.
Primero explica este término: en realidad es muy gráfico. Un pago transfronterizo en una sola traza: en los dos extremos están las monedas locales, y en medio hay una capa de stablecoin pública. El pagador convierte su moneda local en una stablecoin en dólares; la stablecoin realiza la liquidación transfronteriza en la cadena; y el receptor, a su vez, la convierte de nuevo a su moneda local. ¿No es como dos rebanadas de pan con esa capa intermedia en medio? Esa es la forma en que la industria empezó a describir la liquidación transfronteriza con stablecoins.

En la comunidad cripto se ve cada semana: “algún gran magnate de las finanzas tradicionales se lanza al blockchain”. Ahora, cuando veo este tipo de titulares, básicamente los paso de largo, porque en la gran mayoría de los casos al final se quedan en laboratorios de innovación: publican un comunicado de prensa y no hay más novedades. Para determinar si es verdad o no, hay un criterio bastante sencillo: si un cliente común, desde su propia app, puede abrirlo y usarlo directamente.
XP Inc. Esta vez se ha cumplido con este estándar.
Primero, aclaremos qué tipo de empresa es, porque el tamaño determina la importancia del asunto. XP es una plataforma de inversión brasileña listada en NASDAQ; su ticker es XP. Revisé los datos del primer trimestre de 2026 en su página de relaciones con inversores: el patrimonio de clientes está en el orden de R$1.529 mil millones de reales, es decir, R$1.529 billones; asesores/inversionistas registrados superan los 18.000; y en los últimos doce meses los ingresos totales fueron de R$19.8 mil millones de reales, con una utilidad antes de impuestos de R$5.8 mil millones de reales.

Para ser sincero, cuando se trata de noticias de tipo colaborativo, yo normalmente les echo un vistazo y paso; de diez, nueve solo se anuncian cruzando logos. Pero esta vez me detuve y la leí hasta el final, porque toca el eslabón más básico y también el más caro de los pagos transfronterizos.
Las transferencias internacionales son lentas; mucha gente cree que es por “internet lento”. La verdadera razón es más banal: el dinero no se “envía” realmente, sino que ya estaba “depositado” allí. Para que un banco pague a un país determinado, normalmente tiene que abrir una cuenta en el banco local con antelación y dejar una gran suma; en jerga se llama cuenta nostro. Cada corredor de pago global tiene que “apartar” una cantidad, como si depositaras un manojo de efectivo en casa de cada amigo, por si algún día pasas y lo necesitas. El dinero se queda inmóvil en la cuenta, y las fluctuaciones del tipo de cambio las absorbes tú; una transferencia internacional puede tardar varios días en completarse.

Para ser honesto, cuando vi estas tres siglas juntas por primera vez, pensé que eran tres respuestas a la misma pregunta: cuál es más rápido, cuál es más seguro, y ya está. Luego entendí que ponerlas en un ranking, es como preguntar: "¿Qué herramienta es mejor, el martillo, el destornillador o la llave inglesa?" La respuesta depende de si lo que tienes delante es un clavo, un tornillo o un perno.
Cada uno de ellos resuelve en realidad tres problemas que se han mezclado en uno.
El primer problema es: quiero demostrar que algo es verdadero, pero los datos necesarios para demostrarlo son sensibles, y no quiero mostrártelos. El banco quiere explicar al regulador que "esta transacción es legal, está autorizada correctamente y no hay duplicados", pero no quiere desglosar el importe y el pagador/receptor en los libros contables. Esta necesidad de que la prueba sea verdadera, sin revelar los datos, es el terreno de ZK. Su encanto consiste en que la garantía proviene de las matemáticas, no de "te prometo que, aunque no lo veas"; un regulador o auditor que reciba la clave de verificación puede comprobar la conclusión, pero no puede acceder a los datos subyacentes. El costo también es bastante tangible: es excelente demostrando propiedades de los datos, pero no tanto para que varias partes calculen conjuntamente cuando ninguna tiene datos completos, y además consume más potencia de cálculo que el texto en claro.

Hermanos, llevo mucho tiempo en acecho en la comunidad Rayls. Sé que todos están muy descontentos con el equipo; yo también, pero el equipo sí está haciendo trabajo de verdad, y lleva tiempo esforzándose. Lo único es que el equipo de Rayls sigue una ruta conforme a las normas. Hermanos, no se rindan; todo quedará en manos del tiempo. Creo que el equipo de Rayls finalmente entregará los exámenes que nos dejarán satisfechos. Voy a compartir con ustedes buenas noticias: se trata de que recientemente el equipo de Rayls se conectó a RPC. ¡Esto es algo muy importante!
Resumen rápido
¿Qué es RPC?
Puedes entender RPC como una línea telefónica dedicada entre la aplicación y la blockchain.