Atticbee

Four dining philosophers problem coded in ToLang (Tuplespace Operation Language), compiled into TVM bytecode executable and run on TVM (Tuplespace Virtual Machine). All philosophers are fed! @alux_network @rhovision

🔗 ALUX Roadmap Update In the first quarter of 2026, the team continued progressing toward a fully functional, integrated system. During this period, several critical issues were identified—particularly bugs that caused cross-block execution to stall and replay mechanisms to fail. These findings led us to redesign the replay mechanism into a simpler and more elegant solution, enabling reliable cross-block atomic execution. At the same time, significant portions of the codebase are being refactored to improve modularity and extensibility. A new EVM sandbox architecture has also been proposed, simplifying the interaction between the EVM and TVM while improving overall performance. 🚀 Looking Ahead to Q2 In Q2, our primary goal is to close the loop by successfully completing a full end-to-end integration test of the entire system. The upcoming demo will showcase: ⚡ Atomic cross-block execution in action 🔧 A real-world use case: orchestration of smart contracts using async/await, join, and select This milestone represents a critical step toward validating the system as a cohesive whole—demonstrating not just individual components, but their integration into a working runtime. 💡 Why This Matters Achieving reliable cross-block atomic execution is foundational. It transforms blockchain systems from isolated transaction processors into coordinated execution environments 🧱→🌐, enabling more complex, stateful, and concurrent applications. The Q2 demo is not just a feature milestone—it is a system-level validation of ALUX's core architecture. Stay tuned! 👉 alux.network/roadmap #Web3 #Concurrent #Composite #Blockchain $ALUX

The 2026 Web3 inflection point won’t be faster blockchains, but trustless collaboration between AI agents. Today, the execution model of most blockchains is still based on: instant short transactions, ordering, and then sequential or parallel execution with synchronous calls. This model is almost unusable for an agent economy. A blockchain that can truly support an agent economy needs: ⚡️ Coroutine-style transactions (pause / wait / resume + ACID) ⚡️ Process orchestration primitives (join, select, async coordination) ⚡️ ACID cross-shard execution (true horizontal scalability) ⚡️ OCAP-native security (secure agent-to-agent interactions, preventing prompt injection attacks) When AI agents begin executing autonomously on-chain: Blockchains without a concurrency model will become the biggest architectural bottleneck, and systems without capability-based security will become the largest security vulnerability. A distributed concurrency control layer will be the key infrastructure for the Web3 × Agents era. $ALUX #Web3 #AI #Blockchain #AIagent

@Szaonly666 Got it, so there is no ACID guarantee across async points. ACID is only kept at block level through block-STM style concurrency control.

@atticbeeus That’s why event driven execution and protocol level schedulers matter. You can weakly isolate async orchestration while enforcing serializable semantics inside execution segments. Think MVCC + deterministic event queues instead of monolithic ACID.

Async on blockchain is not a dev convenience It’s a paradigm shift, Rialo treating programs as async is massively underrated. Most chains are synchronous by design, This forces polling, bots, cron jobs, and fragile middleware. Async programs mean contracts can wait for real world events natively, No keepers, No external orchestration hacks. Think: 1. Web callbacks 2. Cross chain triggers 3. Payment automation 4. Agent workflows All as first class primitives. This moves blockchain from transaction machines → event driven systems, Closer to modern distributed systems design For builders, async removes the cognitive tax of simulating reality with block numbers and polling loops. For users, it means apps that react instantly to the world, Not clunky DeFi scripts pretending to be software. Async is how real software works Rialo importing this paradigm onchain is how Web3 becomes real world software, not financial Lego.

@Szaonly666 In financial apps serializability is expected by default. Though we can shrink the scope of serializability - the tx as whole can be weakly isolated but a sub execution block (may across async points) can be required as S.

Atomicity across blocks requires protocol level orchestration (e.g., saga style workflows or 2PC primitives) Otherwise you only get best effort consistency. Serializable isolation is approximated via deterministic scheduling, MVCC style state versioning, or domain scoped locks not global serializability, which would nuke throughput.

👨🏻‍🎨 ALUX roadmap update! 1/ In Q4 2025, we continued advancing atomic cross-block long-transaction (long-TX) support. Long-TX test cases now run successfully with hardcoded sync points—putting us one step away from our first major milestone. 2/ Next step: replace those sync points with BlockGit consensus. That unlocks our first working demo: fully on-chain, atomic long-TX execution across multiple blocks. 3/ We also refactored the codebase to improve modularity. These upgrades lay the groundwork for: - faster, more flexible evolution toward sharding - extensions beyond blockchain-only use cases 4/ In parallel, we explored several logical clock designs to capture execution traces efficiently—enabling analysis and enforcement of different transaction isolation levels. Implementation is now underway. 5/ Looking ahead to Q1 2026, our primary objective is clear: Pass integrated tests for atomic long-TX execution on top of BlockGit consensus. This milestone will serve as a proof of concept for our novel blockchain design. 6/ After that, we’ll focus on production-ready features needed to launch a functional testnet. 7/ We’re community-driven—and we wouldn’t be here without you. Our small but capable team continues to deliver, addressing engineering challenges rarely faced by other teams. 8/ A quick look back at our journey: 2022: Built an OCAP-enabled bytecode interpreter + the Tolang compiler 2023: Implemented the tuplespace virtual machine (TVM) with replayability 2024: Built the EVM sandbox on TVM, implemented the Block Merge algorithm, and developed BlockGit 2025: Introduced behavior channel types + completed key components required for atomic long-TX support 9/ Even as the industry cools again, our vision is clearer than ever: Make all forms of state transitions possible in centralized systems equally possible in decentralized ones. A real world computer as a unified logical VM—composed of many smaller VMs across sharded chains, L2s, private clouds, and browsers. 10/ Smart contracts on this unified VM can call one another seamlessly and finalize atomically—even across different sub-VMs. The OCAP-enabled VM ensures these interactions remain safe and controlled. Atomic on-chain long-TX support is the first critical technology we must deliver—and we’re very close. ----------------- As we enter 2026, thank you for building with us! Stay tuned! 👉🏻 alux.network/roadmap #Web3 #Concurrent #Composite #Blockchain $ALUX

@kernel1983 @Ethan_China2020 @GodotSancho @monad @alux_network @Tau_Net @Conflux_Network DAG跟分片没有任何逻辑关系。 用DAG来组织区块，本质上就是个逻辑时钟，包含了事件（出块依据，交易执行）之间的因果关系。这种因果关系在分布式系统中天然是偏序的，所以用DAG来描述比用体现全序关系的线性链要自然的多。 搞技术的这类争论很常见，可以帮助提升思维，抓住本质，没啥不好

@atticbeeus @Ethan_China2020 @GodotSancho @monad @alux_network @Tau_Net 论技术DAG一哥是@Conflux_Network 而且DAG无法分片 我们到此结束吧，不然你也会很烦恼

最近看到很多关于 @monad $MON 与公链护城河的讨论。作为 L2 的贡献者，真心感觉所谓的「构建生态」，已经被证伪了🥲 如果你从头搭建好了一条公链或者 L2，抱着完全赤诚的心，想建设好项目，那首先要考虑用户和链上资金从哪来。 当你四处求合作，会发现没有人搭理，甚至付费找 KOL 推广都会被拒绝。 这时你明白，大家最基本的需求，是确信你不会跑路，而不是关心你的公链性能和技术。你需要强力的 VC 融资来做品牌背书。 问题是，VC 投资看什么，你得有名校和大厂背景，最好还得有密码学背景，或者拥有密码学背景的合伙人。 假设你刚好都具备，也找到了密码学背景合伙人，顺利融到了资。这时，会有一小部分人顺着融资新闻尝试在你链上撸毛，KOL 也来找你询问合作机会。 然后就会面临一个问题，用户怎么把钱转到你的链上。 如果是公链，在没发币的情况下，只能靠测试网领水。 如果是 L2，要去找跨链桥合作，多数跨链桥都是池对池跨链，所以能到你链上的资金类型非常有限，只会局限在 USDT、USDC 这俩稳定币，和 ETH 及其 LST 资产。 当然资产数量不会太庞大，因为大家还是有点担心你会跑路。 而且最关键问题是，如果链上没有原生 USDT、USDC，那你链上的这俩代币，其实是锁仓在跨链桥的 USDT、USDC 衍生的，一旦跨链桥出现问题，你没有办法为用户兑付资产。 去找 Tether 和 Circle 聊合作？基本费用至少大几百万起步，还是算了吧。 好了，然后你链上的 DeFi 流动性局限在 USDT-USDC 交易对和 ETH-wstETH 交易对，毫无意义可言。 依靠跨链桥来到你链上的资产明显不足，流动性的中心是交易所，要是交易所能开放你的公链提币会是很大帮忙。 然后会发现绝大多数交易所上币是要收费的，最大的那家不收费，但是要对他们有价值。恭喜你，拿到 KPI 了。 TVL 怎么办？只能一家一家找机构、BD 巨鲸和大户，承诺收益。等发币了，用代币补足对方贡献 TVL 的 APY。 链上活跃呢？已经成熟的大 DeFi 项目不会理你，除非你能承诺给于巨大的流动性，也就是部署至少千万美元或者过亿美元的 TVL 到该项目，他们才会考虑在你链上部署。否则，深度不够，没人用，人家部署了也没有意义。 GameFi、NFT？基本已经死了。 来找你的项目，基本都是冲着 Grant 资助来的，随便抄一个现有项目，部署在你链上，等你发币问你要 Grant，拿到代币就套现，然后多链部署，寻找下一个公链或 L2。 就算他们是真心想在你链上部署，那人家也不会局限在你一条链上。因为人家也要市值。也需要扩展用户群体与市场规模，多链部署是最佳策略。 MEME 在多数人眼里是一个好方式，很多人觉得拉盘几个 MEME，链就能搞得定。但实际情况是，MEME 不能自己发，毕竟很多国家的监管不是吃素的。 其次，你也不能临时招聘一个做市团队，这也是成本。找第三方 MEME 发行团队合作？一开始几个代币可能还稳得住，前提是大户不止盈、不套现。 一旦新增用户变少，实际买盘不足，大户套现，MEME 就会在更低的价格接盘，盘面大阴线越来越多。 高频交易者的加入会让情况变得更糟，他们会拉高 Gas，狙击 MM 还来不及撤销的挂单。于是 MM 只能拉宽买一卖一间距，用户交易滑点越来越大。价格波动也就更猛烈。 慢慢地用户持仓时间越来越短，舔一口就跑。MM 维持价格的时间也只能越来越短。 不断博弈的结果就是比谁跑得快。最后，终于谁都不用跑了。 如果你最后侥幸达到了 KPI，终于要上币了。有个问题需要解决，VC 的利益你要不要保证？给你贡献 TVL 的巨鲸和大户呢？生态项目的 Grant 呢？MM 的流动性配资，交易所的上币空投、Stake 奖励，以及给用户的空投，还有团队。这里面你保住谁的利益，又该牺牲谁的利益呢？ 最终你上币成功了，但交易所还是只会开放你的本币在链上的充提，最多加个 ETH。 Tether 和 Circle 依然收费大几百万到千万美元，链上就没有原生的 U，交易所没法开启基于你的链的 U 的充提，DeFi 巨鲸是不会相信跨链桥的安全性的，不会将大额资金跨链过来。 用户参与你链上活动，需要提你的本币，然后到链上再卖成 ETH 或者 U，其中的磨损本身就是门槛。 哦对了，没有原生 U，也就别指望会有 RWA 来部署了。甚至你的预言机，都用不了 Chainlink，因为他家收费也超级贵。 最后会发现，发行一条通用链来构建生态，是一个伪命题。 这其实就是一场巨大的「皇帝的新衣」，买盘也不是基于你的基本面，而是阴谋论，是感觉你背后有某某某坐庄，某某某支持。 你会发现自己链上的资金，最终还是会回归 ETH 和 SOL，可能还有 Base，这些链的马太效应已经非常明显了。 交易所开放的资产充提支持、链上已有资产流动性、DEX 的资金和交易滑点、DeFi 间规模和联动效应、DeFi 协议的种类和可组合性、现货合约期权等等不同交易类型、仓位能否对冲、能否构建债券产品、借贷协议的清算安全性，甚至是用户的交易习惯、用户已经形成的固定印象和路径依赖等等等等，全部都是这些成功公链的护城河。 所以，又回到那个为什么，用户为什么一定要用你的链，生态协议为什么一定要基于你的链部署？重要的不是技术本身，而是独特性。 这个独特性必须对交易和收益，这两大场景有帮助。而且得是共识层面的帮助，就像 Hyperliquid 撤单优先共识排序利于 MM 提供流动性，或者是 Solana 正在开发的 ACE 应用控制执行。 其实写到这里，我已经表达完了。 最后的最后，想说所以 Manta 孵化的项目，不会强制让其部署在 Manta 链上，而是可以自由选择觉得适合自己的链，比如 superfortune 在 BNB Chain 上，Junk.Fun 在 Solana 上等等。但他们的部分收入，需要回购 MANTA 。 以上。

@kernel1983 @Ethan_China2020 @GodotSancho @monad @alux_network @Tau_Net DAG是一个数据结构，描述的是区块之间的逻辑关系，本身当然不是共识协议。 DAG要变成共识协议，要加上共识算法。对于一般链就是：根据我看到的当前DAG，怎么提取出到达下一个状态点的那个输入，也就是用于计算下一个状态的一批区块以及上面交易的排序，同时保证其他人也会得出同样的决策（安全性）。

@atticbeeus @Ethan_China2020 @GodotSancho @monad @alux_network @Tau_Net 无法说服我，DAG甚至不是共识协议

@kernel1983 @Ethan_China2020 @GodotSancho @monad @alux_network @Tau_Net 绝大部分都是先共识排序，然后再确定性的执行交易，完成状态转移。 HyperLedger是个例外，它是先执行再共识，不过共识机制不适合公链。

@Ethan_China2020 @GodotSancho @monad @alux_network @Tau_Net 哪个链不是先执行再共识呢？翻篇吧

@kernel1983 @Ethan_China2020 @GodotSancho @monad @alux_network @Tau_Net 单分片版本只有一个main branch，到了多分片就有多条分支了，很好玩。 具体细节很多，等我们公布paper以后欢迎指教

@kernel1983 @Ethan_China2020 @GodotSancho @monad @alux_network @Tau_Net BlockGit是 @alux_network 开发的基于DAG的共识协议。取这个名字是因为alux特有的“先执行再共识”的机制，使整个系统的行为类似各个validator是独立码工，在自己本地repo的main上执行交易，随后打包成一个块（“PR”），共识协议负责不冲突的“PR”们可以merge成一条共同的main。这是并发长交易上链的基础

🙋🏻‍♂️ In Q3 2025, we focused on building a key mechanism to enable long transactions — on-chain transactions that can be temporarily suspended and later resumed, allowing execution to span multiple blocks while remaining atomically finalized. This marks a major step toward true scalability, paving the way for the world’s first blockchain capable of actively interacting with the off-chain world, instead of relying solely on oracles. The same mechanism will also power atomic cross-chain transactions in the upcoming sharding phase. Meanwhile, we have continued improving code quality and modularity through multiple refactors across the TVM and database modules, as the system grows in complexity. Next quarter, we will focus on integration and testing, moving closer to a working demo — the first blockchain capable of concurrent, on-chain long-transaction processing. Stay tuned! 👉🏻 alux.network/roadmap #Web3 #Concurrent #Composite #Blockchain $ALUX

几年前看《三体》，偶得一句以和大刘的那句名言： “光锥之内皆命运， ——视界以外无因缘。” 近来研习范畴论偶有所思，故又续上三联： ​光锥之内皆命运，视界以外了因缘。 ​洛引有情藏定数，湍流无序乱循环。 ​缠绵波象印虚境，不尽熵增归寂然。 ​敛罢微参真智现，茫茫态射衍诸般。

🧑‍🏭 In Q2 2025, we completed a critical enhancement to our TupleSpace Virtual Machine (TVM): the introduction of simple behavioral channel types. The TVM bytecode standard now enforces three channel types—Single-Owner, Affine, and Linear—enabling significantly faster execution and a much smaller replay log, all while maintaining replay consistency. 🦿 Our Weaklink feature in BlockGit has also passed full testing. Unique to ALUX’s protocol, Weaklink decouples a block’s two roles: contributing to consensus state and to virtual machine state. This separation is vital to achieving ALUX’s vision of supporting on-chain long transactions and atomic cross-shard transactions. 🤖 As we integrate all modules toward a working demo, we have introduced a more advanced test framework. Using Rust’s proptest crate, we built a system that generates millions of random Tolang programs to test TVM execution under various concurrent schedules. Each test ensures state consistency between play and replay across hundreds of execution paths. 🫶 Looking ahead to Q3, we remain focused on delivering a demo showcasing a blockchain capable of processing long-running transactions on-chain. Stay tuned! 👉🏻 alux.network/roadmap #Web3 #Concurrent #Composite #Blockchain $ALUX

As part of a recent upgrade to our TupleSpace Virtual Machine (TVM), ALUX has introduced new behavioral channel types to enhance performance and predictability: ※ Single-Owner: A name (channel) is exclusively owned by one process at any time. ※ Affine: A name may be used at most once. ※ Linear: A name must be used exactly once. These constraints are enforced at runtime by our bytecode VM, enabling more efficient execution paths. Why it matters: ALUX is building a Pi/Rho calculus-based VM designed for composable, long-running concurrent transactions on-chain. To scale without compromising performance, we’ve introduced a class of channel types that unlock key optimizations. For example, Single-Owner channels support lock-free access and can be used to hold sequential VM sandboxes like the EVM. Affine and Linear channels ensure deterministic usage, reducing the overhead of recording extra information for validator replay. This is where formal theory meets practical engineering—ALUX brings it to life. $ALUX #Web3 #Blockchain #Concurrent #EVM

The evolution of the Ethereum Virtual Machine (EVM) can be understood across four distinct levels: Level 1: Sequential EVM (e.g., Ethereum) * Transactions are processed sequentially, one after another. Level 2: Parallel EVM (e.g., Sei, Aptos, Monad) * Enables parallel transaction processing for improved throughput. * Limitations: Depends on trusted oracles (such as Chainlink) to interact with the external world. Level 3: Concurrent EVM (ALUX – Single-Shard Stage) * Supports asynchronous, long-running transactions that can be temporarily suspended and resumed. * Enables direct, active communication with the external world—without relying on intermediaries. Level 4: Composable EVM (ALUX – Multi-Shard Stage) * Allows transactions to run across multiple shards while preserving atomicity. * Unifies shards into a single, logically cohesive virtual EVM. * The only approach to achieve horizontal scalability without compromising usability. $ALUX #Web3 #Blockchain #Concurrent #EVM

@gakonst The very reason current L1 chains can only support record keeping type of job is all TXs must be (atomically) finished in one block. Huge restriction. Chains can't do async calls to external systems and await for the result. Shards can not be virtualized into one logic VM.

@gakonst "blockchains are just decentralized record keepers." - it's only the current state of art. But more general state machines capable of executing concurrent long running txs need to be supported by blockchains. The benefit would be enormous. We are retrofitting EVM to achieve this

The EVM is IMO the most secure and usable of all the crypto VMs. You can convince yourself of that by comparing the e2e devex of a Foundry user vs anyone else. The verbs you care for: Build, test/fuzz, docs, verify, sim against forks, trace, debug. Doesn't even come close. The thing people don't get is the VM doesn't matter for a network's performance. The underlying VM determines how secure the record keeping and how accessible it is to devs, not how fast it does it. Check the profiles... The language you talk to the VM is tailored to the idiosyncracies of a blockchain's state model...Even if we deployed a RISC-V runtime for Ethereum based blockchain and let people write Rust contracts, they'd look super different to Solana Rust. Why? Because you always need a way to interact with the chain via syscalls to write and read to the database outside of the VM! And that is specific to the chain's state model. Why? Because blockchains are just decentralized record keepers. Most of the time is spent doing...record keeping! And some light math, but not too much (think an options pricing algo, not a 70B LLM). Focus on the security and the usability for the devs! The performance comes from other tradeoffs around network topology and accessibility to node operators!

@gakonst In addition, blockchain state should be better compartmentalized with built in object capabilities support, which is also missing in EVM. So we designed a VM with opcode level support of OCAP. EVM instances can run concurrently(not parallely) in our OCAP compliant VM's sandboxes.