0xANDev

Greetings everyone. Here’s an update or , a more of my thought process . Gate is set (Alpha I) Now next priority, Revisit consensus mechanics. The idea, how do I get a consensus mechanism that trust no one, requires no human (which always cheat and have the ability to act maliciously) , leaderless solution and most importantly fair and never can be gamed forever? My answer .. A mathematical absolute resolution system (MARS). How so? I’ll use VDF as beacon that seeds a parameter. Define crazy details perfectly deterministic protocol rules that uses an element that is not bias and truly fair and game resistance (even with brute force) What is it? MATHEMATIC! Yes. Maths. Slot ‘n’ is seeded with vdf beacon seeds and then relies on previous block hash (which is truly unique) , and I’ll define strict sets of everything from txn formatting to protocols and everything deemed to be deterministic. Some rough sketch would be : how beavon advance ? compute yₙ = VDF(yₙ₋₁) header? Hₙ = { version, slot = n, parent = hash(Hₙ₋₁), beacon = yₙ } VDF? Eval(x) -> (y) (sequential) Prove(x) -> π (need to be careful with this) Verify(x, y, π) -> {true,false} input x for slot n is y_{n-1} (the previous beacon output) output is y_n Now the beacon y_n is valid iff there exists a proof π_n such that: Verify(y_{n-1}, y_n, π_n) = true there’s alot more actually, defining header, header ID and stuffs, to make header is single, canonical and ensures there’s always a single possible header anywhere anytime at any given situation so no forks instant finality no rollbacks and reorgs . boy .. crazy stuff . we are on the unchartered territory. big dreams ahead, stay cohesive everyone . $OBEX !

back at my desk. had intensive physiotheraphy session for pass 5 days. lets go obex.

@eKnonos @nonossystems NONOS should be sovereign; solutions that aren’t sovereign are just another monitor. That is a respectable mission. Kudos @eKnonos

With single self contained header that can reconstruct the whole block as a powerful single envelope, we will foster a very fast propagation and making all nodes light. Also, Since there’s no voting required and just maths of validity = finality we dont have to waste time for consensus. math itself is the consensus. maths itself is the ‘vote’ results? no centralization, leaderless, humanless, ungameable mechanism. the rough sketch here .. it means , blocks are ‘ephemeral’ , reconstruct if needed (for verification etc.) so no bloat . crazy ambitious.. but that’s what $OBEX is here for. the game name is ‘Redefinition’ !

Hold boys, million runs to observe consistency is good, but with ~330ms per run, it would equate to to 83 hours. We cant waste time just for testing right? I was thinking.. Probably, I can make the benchmark support “huge run counts” safely by streaming stats + histogram + periodic reporting, and add a ''--max-seconds' cutoff so I can collect enough data without the need to wait for multi-day run. Then I’ll run a realistic stress sample (e.g. 60–300 seconds) and look at p50/p95/p99/max jitter. It's just statistics power hacks, not cheating haha. I ensure to update soon. Just bear with me for now, I'll explain later, when everything made sense. $OBEX

Dev Log Running `target\release\vdf_test.exe --target-ms 300 --runs 15` === Chia VDF Benchmark === Challenge: "obex_alpha_i_identity_challenge_v1" Generating discriminant (1024 bits)... Discriminant: 63.1618ms Target mode: aiming for ~300ms over 15 runs (warmup 2). Warmup 1: 10000 iterations -> 364.8321ms | Verify: OK Warmup 2: 10000 iterations -> 332.3006ms | Verify: OK Calibrated: 11817 iterations (~200 bytes proof) Run 1: 11817 iters -> 302.835 ms | proof 200 bytes | Verify: OK Run 2: 11817 iters -> 315.434 ms | proof 200 bytes | Verify: OK Run 3: 11817 iters -> 329.357 ms | proof 200 bytes | Verify: OK Run 4: 11817 iters -> 308.374 ms | proof 200 bytes | Verify: OK Run 5: 11817 iters -> 342.977 ms | proof 200 bytes | Verify: OK Run 6: 11817 iters -> 304.887 ms | proof 200 bytes | Verify: OK Run 7: 11817 iters -> 306.178 ms | proof 200 bytes | Verify: OK Run 8: 11817 iters -> 321.440 ms | proof 200 bytes | Verify: OK Run 9: 11817 iters -> 303.383 ms | proof 200 bytes | Verify: OK Run 10: 11817 iters -> 317.394 ms | proof 200 bytes | Verify: OK Run 11: 11817 iters -> 310.564 ms | proof 200 bytes | Verify: OK Run 12: 11817 iters -> 317.904 ms | proof 200 bytes | Verify: OK Run 13: 11817 iters -> 313.530 ms | proof 200 bytes | Verify: OK Run 14: 11817 iters -> 329.707 ms | proof 200 bytes | Verify: OK Run 15: 11817 iters -> 580.969 ms | proof 200 bytes | Verify: OK Stats (ms): mean 333.662, stddev 69.336, min 302.835, max 580.969 $ Here's what I observed, The spot is 10K iterations. But stddv is concerning, probably noise. 15 runs wont do it, imma do million runs and observe again. $OBEX

We are into something gentleman, chiavdf of ‘Chia’s’ in C++ tamed and made it work in pure rust . Now I am trying to find the sweet spot and number of iterations to land it sub-second. Need more testing, experimenting and numbers manipulating, proper way is to write some bench scripts. Pray for our dream. $OBEX

@skanderium thank you 😁

@aminnizamdev Good luck Amin, great update, thank you !

An update guys, yesterday, all day ive been running the SHA3 recursion setups and it’s consistently achieved sub-second delay , roughly in the range of of 420ms-550ms with 500k~ ish recursions . it works, its fast. but im still concern about the tradeoff of security, especially the precompute resistance part. with vdf , it is guaranteed resistance, without it, it’s not guaranteed. so, last night i revisit my drawing board. although chiavdf is not in pure rust, but with CMake + LLVM it is possible, just a little bit more complex. thats what im trying to test and achieve today, if it’s a success , then boy … it’s better and more secure than the old setup. let’s look at the old setup : 512 MiB , 16.7 Million Leaves of 32b , q=96 challenges, merkle leaves setups, RFC 9381 RISTRETTO, 3 passes + vdf that seeds it . score : 98.8% powerful, clean, but excessively heavy what ive been testing yesterday : 1 MiB , still 32b leaves, still 3 passes, ECVRF RFC 9381 RISTRETTO, same q = 96 challenges. dropped the vdf and replace it with 500k SHA3 recursion. score : 92.5% slightly less powerful but powerful regardless, clean, blazingly fast, sub-second goal is guaranteed at standard machine, but not precompute resistance . hold up there’s more, what i will test today : 1 MiB , 32b leaves, 3 passes, ECVRF RISTRETTO RFC 9381, merkle tree setup, q = 96 challenges, SHA3 500k recursion (this is NIST standard , which means it’s quantum computer resistance) , + chiavdf import from Chia but tuned with CMake + LLVM to suit the pure rust project . IF it’s a success, it will be more powerful, more secure, still and absolutely blazing fast, but lighter . if it’s a success , i would rate it 99.7% score the vdf will seed everything . $OBEX !

Dev Log, Guys, ive been retesting the engine of Alpha I , the normal setup : 512 MiB, 3 passes 16.7 million leaves of 32b from ram hard. q derived 96 challenges. yes it’s good, yes it’s sybil deterring, but when i tried to a smaller laptop, it struggles and resulting OOM (memory crashes/denies) so, i tried experimenting with down scaled version of 512MiB , yes it’s runnable. yes works absolutely goof and blazingly fast even in small laptops but that’ll cost us the security, it’s a tradeoff. so i do a deep study to find a solution, i was thinking to incorporate SHA3 hash recursion, did a bench from 200k iteration to 20M iteration, the sweet spot is around 500k~ ish iteration. SHA3 recursion is used by Solana in their architecture, it’s not as battle tested like SHA256 of bitcoin, but it’s been there and used by solana for almost 4 years now. so , im testing if we can do this, highly accessible for everyone , but still secure . my theory is this, although the we only run 1 MiB , the prove is mantained the same , with q = 96 challenge, this is trivial, so , i added sha3 recursion that requires previous answer to recurse forward. so sybil cost scaled with identities. did a bench on it, it serves the same purpose of VDF delay. but VDF is still superior. but, with sol obex as another gate , i think it’s doable . here’s the update so far . the current replacement setup ive been testing : 1 MiB, 500k+~ ish SHA3 recursion. q = 96 challenges, vrf seeds from rfc 9381 ristretto (elliptic curve) , merkle tree setups and everything else the same the problem, all vdf out there is not compatible with pure rust $OBEX is build with pure rust, they are either C/C++ env or wrapper , yes rust but i need CMake C LLVM and stuffs . chiavdf from Chia project is made from C/C++ so either we go for SHA3 recursion, and find a way to secure . high level understanding : with vdf - unpredictable ? UNDENIABLY slot binding ? yes verifiable ? totally precompute resistance ? absolutely, without vdf (means using SHA3 recursion) unpredictable ? (yes, but limited until parent block known) slot binding ? yes verifiable ? totally precompute resistance? (no, instant once parent known) There must be a way.

@pumpeverything @Crypto_peet People speculate. Everyone has their own opinion. Let’s not talk about people, and focus with the work.

@aminnizamdev Bro can you please clear why @Crypto_peet calling this $OBEX is a larp

GM. Once said, “Showing up is what matter the most” Let’s walk the talk. $OBEX

GM everyone, beloved and most respected community, I’d like to briefly share the current status of the project, some hurdles I’m encountering, the plans to resolve them, and what’s coming next. Phase 3 should have been finished by now, but we’ve slipped slightly from the projected timeline due to some unforeseen challenges. Rest assured, we will push this through. I would love to give you a new timeline and deadlines, but I’m afraid of disappointing you again if I don’t deliver exactly on time. I hope you can understand the situation: I’m working on the project daily, actively debugging issues, and constantly thinking about how to fix them. The issues are resolvable. I don’t have an ETA yet, but I do have a clear plan to resolve them effectively. It will, however, require a slight delay. Current state of the project : 1. Alpha engines (I, II, III and alpha-T) These have been implemented and the codebase is solid. What remains is hardening: security tests, failure tests, edge-case tests, and KATs. Writing the tests is straightforward; running full end-to-end testing takes time (estimated 2–3 days). 2. Network architecture (node propagation, headers, topology, etc.) This is not yet implemented. The previous testnet ran from a central server and a central orchestrator to simplify things, which is why it was smooth. To go to full workable testnet, we need to build a proper network architecture so that nodes can connect to each other (e.g., via P2P, gossip protocols, etc.). Estimated: 4–6 days for implementation, plus 2–3 days for testing. 3. Server and database Right now, Obex runs in 2 modes: local database and cloud database. To make this with good quality grade, I need to design the database architecture properly how to store accounts (addresses), their details, and keys in a secure environment. For now it’s managed by a cloud server, it’s secure, but basic. Estimated: about 3–4 days for implementation, plus 1 day for testing. Once we complete this round of development, fixes, and testing, we will move to Phase 3: polishing the UI and getting Obex ready for investor pitches. Serious development is quality development, and quality development requires serious time and effort. I really hope you can give me the space and time to execute this properly. Your support means everything to me, and I will give my best every bit of effort I have to deliver. however good the technology or the codes is , it’s just numbers and alphabets in the github repository, it’s the people , the support and the convictions of the community that push and make a project excel . it’s them who actually make it valuable . with my humblest heart, i apologize for the delayed and the bad communication etiques for the past few weeks . striving to do better Thank you for your patience. Thank you for supporting the project. Thank you for being part of this community. Much love, aminnizamdev ✊🏻

Showing up is what matter the most.

Update :: Service Suspension The Obex official website (obexprotocol.io) and the Obex testnet environment (obexprotocol-testnet.io) have been temporarily suspended for further development and enhancement. Both services will remain offline until further notice. We will provide updates as progress is made. Thank you for your patience and support.

Announcement :: X Space (this Sunday) I will host an X Space session this Sunday. Objectives - Thank new members for joining the community. - Present the Obex project’s vision and goals. - Improve observers’ understanding of the project, answer questions, and encourage informed, long-term support. I will schedule and pin the session on my X account: @aminnizamdev.

@88il988 purpose if I may, sir?