Waves Dev Jedi | RIDE for dApps
09 March 2026 15:07
If everything works...
Читать полностью…
Waves Dev Jedi | RIDE for dApps
09 March 2026 14:50
docker compose logs -f | grep -iE "error|warn"
Читать полностью…
Waves Dev Jedi | RIDE for dApps
09 March 2026 14:46
I'm not a programmer! What should I enter into the terminal?
Читать полностью…
Waves Dev Jedi | RIDE for dApps
09 March 2026 14:42
Where is my mistake?
Читать полностью…
Waves Dev Jedi | RIDE for dApps
09 March 2026 14:39
I just don't know how to help you at this point
Читать полностью…
Waves Dev Jedi | RIDE for dApps
09 March 2026 14:35
You still have 13 nodes! That's a lot!
If no one can help me!
I'm not a programmer! I'm just maintaining the node! And these requests are coming to me? Decide! Do you need an additional node or not?
Читать полностью…
Waves Dev Jedi | RIDE for dApps
09 March 2026 14:27
and I would love to see more
Читать полностью…
Waves Dev Jedi | RIDE for dApps
09 March 2026 14:27
I'm thankful for all running WAVES blockchain nodes
Читать полностью…
Waves Dev Jedi | RIDE for dApps
09 March 2026 14:23
I thought this would help your situation not discourage you :(
Читать полностью…
Waves Dev Jedi | RIDE for dApps
09 March 2026 13:23
That sounds like a perfect opportunity for an expert who knows everything about in running a WAVES blockchain node to build an AI SKILL waves-node-expert? The skill would include all the things about a WAVES blockchain nodes ... facets, RPCs, dbs, hardware, hosting, costs, deals, versions, downloads, install, watchers & stats dashboard, deploying, updating, upgrading, UNIT0, etc.
The skill package could have the skill set that maintains, updates and continues to learn how to make running a WAVES blockchain node better and better to ensure that it is always using the best practices. Then get it verified (by the expert [same]) get feedback, make it better and oss the skill for others to use to maintain perfect WAVES blockchain nodes.
Build it and projects will have AI deal with maintaining an awesome node. Many in this group are WAY more qualified than I to be this expert, but building one is 100% on my agenda next week
Читать полностью…
Waves Dev Jedi | RIDE for dApps
08 March 2026 16:39
would someone send 300 testnet WAVES over to 3MyRWStgHKPnU8B8r44Yww6u5APGQD2hQru
Deploy a testnet facet is on the TODO list, but I need to test some other stuff now. Thanks
Читать полностью…
Waves Dev Jedi | RIDE for dApps
08 March 2026 07:19
Tell me how to do this?
Читать полностью…
Waves Dev Jedi | RIDE for dApps
08 March 2026 04:52
How do I check block heights? There might be a sync issue.
Node version 1.6.1
Читать полностью…
Waves Dev Jedi | RIDE for dApps
07 March 2026 20:06
Aligned WXG Buyback
-
We’re so close to getting this proposal approved! 🤏
If you haven’t voted yet, now’s the perfect moment to jump in and drop a YES. Every vote counts and we’re almost there! 🚀
Читать полностью…
Waves Dev Jedi | RIDE for dApps
06 March 2026 13:43
This is a really elegant architectural pattern.
The core idea: separate data storage from execution
Right now the proposal is trying to do two things in one transaction:
📦 Carry 61 node configs as payload
⚡️ Execute the setLeaseNodes logic
The "Solana way" splits those into two separate steps.
Step 1 — Write the config to on-chain storage first
Use a Data Transaction (type 12) to store the node list in an account's key-value storage.
Data transactions have a much larger limit (~140KB, 64 entries per tx) — completely separate from the 5120-byte InvokeScript cap.
You'd write something like:
[
{ "key": "nodeConfig", "type": "string",
"value": "3PA1K...=20|3P3RZ...=23|..." }
]
This transaction is cheap (~0.001 WAVES per entry) and has no meaningful size problem for 61 nodes.
Step 2 — InvokeScript just passes the config addressInstead of embedding the huge node list, the InvokeScript only needs to pass the
address of the account where the config lives — that's 26 bytes. The contract then reads the data from that address on-chain:
# Inside the RIDE contract
let configAddr = Address(base58'3PxxxxxxxConfigWallet')
let nodeList = getString(configAddr, "nodeConfig")
# ... process nodeList ...
The InvokeScript transaction stays tiny because it's just a pointer, not the payload.
"Solana way"In Solana's architecture, programs (smart contracts) and accounts (data stores) are completely separate by design — programs are stateless and always read from account storage. It's the dominant pattern over there. WAVES doesn't force this pattern, but the same principle applies: pre-stage large data as a Data Transaction, then invoke logic that reads it.
The practical catch 👇
This only works if the
setLeaseNodes RIDE contract is written to accept an address argument and do
getString() reads from it — or whoever controls a wallet can write the config to AND the contract already does external data reads. If the current contract only accepts an inline string arg, the contract itself needs updating first, which is its own governance proposal.
So the full flow would be:
[wallet]
→ Data Transaction: writes nodeConfig string
[InvokeScript to WavesDAO]
→ arg: wallet address (26 bytes)
→ contract reads nodeConfig from that address
→ executes setLeaseNodes
Cleanest solution of the three options — no byte cramming, no node trimming, no split proposals. The downside is it requires the contract to support it.
Читать полностью…
-