Is There an Existing Blockchain Data Node with Shared Workflow Support, or Should I Build One?

Below is some insight from TON and Tact's perspective regarding your ideas:

Using TON for Data-Storage Backends

TON's smart contract paradigm is built around asynchronous message passing. This means:

• No Direct Data Pulling: Contracts cannot directly call getter functions of other contracts. Instead, they communicate by sending messages. So if you wish to share data across workflows or accounts, you’d need to design an interface where contracts exchange messages to update or retrieve shared state.
• Asynchronous Communication: Because contracts can reside in different shards handled by different validator sets, any cross-contract data exchange must be asynchronous.
• Testnet Support: TON supports testnet transactions, allowing you to experiment with any new architecture cost-effectively.

Architectural Considerations

Given your idea of a “programmatic-style blockchain node” that uses the blockchain as a backend store (e.g. for text or file resources), you might consider:

• Message-Based Data Exchange: Instead of trying to directly pull data from a resource contract, design your contracts to send messages containing only the optimized, compact data (e.g. hashes or pointers) that you need.
• Off-Chain Processing: Perform heavy parsing or transformation (like converting human-friendly text into binary formats) off-chain. This ensures only efficient messages are sent on-chain, reducing both computation and storage costs.
• State Management: When performing updates (especially in cases where a contract’s compute phase may fail), consider using mechanisms such as commit functions to ensure state integrity.

Final Thoughts

There isn’t a turnkey, out-of-the-box solution within TON that acts as a “blockchain node backend” with rule-based features ready to consume shared data from multiple workflows. However, TON and the Tact programming language provide robust primitives that you can use to build such a system. By carefully handling asynchronous communication and offloading heavy computations off-chain, you could create a custom solution that meets your unique requirements.

If you have further questions specifically about implementing these concepts in Tact or more details on message passing security and optimizations, feel free to ask!

Below is some guidance on building a solution like this on the Ton network, especially if you’re considering using Tact for your smart contracts.

---

On-Chain Data Sharing and Limitations

Remember that on-chain smart contracts on Ton are designed to communicate asynchronously. Because contracts may reside in different shards, you cannot directly query or pull data from a contract. Instead, you must rely on message passing. This means that if you design your node to use blockchain as a backend for shared data, you’ll need to architect your contracts so they exchange messages to update and retrieve state. See the section on “Pulling data from other contract” for more details on these restrictions.

---

Optimizing Data Handling

Since smart contracts should be as efficient as possible, a common best practice is to perform all human-friendly data parsing off-chain. In your design:

• Consider storing only compact, optimized data on-chain (e.g., hashes or binary representations).
• Offload tasks like text or file parsing to off-chain services, reducing computation and gas costs.

This is aligned with the recommendation to handle “string parsing from human-friendly formats... off-chain” so that only the necessary compact data is sent in blockchain transactions.

---

Testnet Transactions and Workflow Integration

Ton’s network supports testnets, which are ideal for experimentation with “free” transactions. If your node is built on Ton smart contracts:

• Use protocols like the Sandbox tool during development. The provided testing frameworks allow you to manipulate aspects like simulated blockchain time, which is crucial for testing complex workflows.
• Ensure your node is designed to work asynchronously, so that different workflows can safely interact with shared on-chain state via predefined messaging patterns.

---

Final Thoughts

At present, there isn’t an off-the-shelf “programmatic-style blockchain node” that exactly matches your description on the Ton network. However, given Ton’s robust support for smart contracts written in Tact, it is a viable platform on which you can build such a system. Be sure to account for:

• The inherent asynchronous nature of interactions.
• The cost and complexity of storing large amounts of data on-chain.
• Integrating off-chain components to handle complex data inputs and parsing, while using the blockchain only for critical data storage (such as hashes or pointers).

If you decide to create one, following these best practices will help you design a secure and efficient system on the Ton network. Feel free to dive deeper into the documentation on best practices for more detailed insights!