ASPECT

#blockchain technology integrator; contributor to Bitcoin ecosystem; co-creator of #ScalingBitcoin; contributor to #Kaspa

[ASPECT @CryptoAspect]

@KaspaCouple @Kaspanyan Absolutely. I am just finishing another project that requires my full attention. Once done, I will retarget toward updates within the Kaspa ecosystem.

[ASPECT @CryptoAspect]

@HocusLocusT @cryptosione @terah4d5 @cryptosione Sparkle has been folded into vProgs. We shared a lot of our R&D with the team and devs who have worked on it are actively contributing to Kaspa and some elements that are helping to facilitate vProgs.

[ASPECT @CryptoAspect]

When Kaspa switched from 1 BPS to 10 BPS, DAA became 10x faster. How “temporary vulnerable” transactions using this approach would be if Kaspa rises its BPS rate again?

There is a “median block time” metric, albeit I am not sure of the ability of the script engine to access it. If that can be facilitated, that can potentially be a much more stable temporal reference… 🤷

[ASPECT @CryptoAspect]

@michaelsuttonil @hus_qy This post made me think of this video - https://t.co/5QtLVqFY6a …it’s a good watch for any engineer :)

[Yuval Avrahami @yuvalavra]

We hacked the AWS JavaScript SDK, a core library powering the entire @AWScloud ecosystem - including the AWS Console itself 🤯

How did we do it? Just two missing characters was all it took.

This is the story of #CodeBreach 🧵👇

[ASPECT @CryptoAspect]

Kaspa testnet-12 went up within a few hours. Impressive!

[ASPECT @CryptoAspect]

@p4bpj Don’t think this has to be any news as this is just a proposal.

[ASPECT @CryptoAspect]

There are multiple factors to consider for something like this. It is a bleeding edge of tech for UTXO-driven systems. It’s a plug and play engine, so its integration is relatively simple. The platform would also benefit from other features such as ability to reference pre-published programs, which hasn’t been researched. There may be potential showstoppers related to processing performance costs. Kaspa is the only high-TPS system out there and extended UTXO execution environment may become prohibitive in terms of performance; …and imposed execution restrictions may negate various benefits, such as ability to create arbitrary ZK verifiers etc.

In vProgs JAM paper I have presented a concept where a RISC-V VM (OP_RISCV) can be integrated into the system to solve for what I consider a very serious problem - each ZK verifier version (say RISC-0 v3) would be embedded into RK consensus and require a hard-fork if the verifier needed to be upgraded (to v4). (Unfortunately for very complex technical reasons, Kaspa does not support soft-forks). OP_SIMPLICITY solves that. Conceptually there can be OP_RISCV as well, but Simplicity is very state conscious (minimalistic) and is designed for UTXO embedding/use in crypto. Simplicity also solves various opcode execution cost estimation challenges (aka GAS/CU costs) as you can determine execution costs simply by looking at the compiled bytecode.

I’ll just add that I believe most native-related asset functionality should be done on the vProg layer since vProgs are Turing-complete. However, if covenants are to be used as vProg or L2-UTXO interfaces (there are other solutions as well), then something like Simplicity would bring much more long-term benefits because it is much more capable than the scripting engine.

[ASPECT @CryptoAspect]

Public nodes has two meanings in Kaspa - public p2p nodes and public User RPC nodes. For example, I want to run a public node to support the network (p2p) but I may not necessarily want to serve client RPC because that can, based on amount of users and subscriptions, siphon large amounts of bandwidth while simultaneously impacting QoS to any user connected to my node. (i.e. my Netflix can suffer :) ). This is why PNN was setup and is built into all Rusty Kaspa SDKs. It load balances multiple contributor ran nodes (with sufficient underlying hardware and bandwidth) providing a sufficient horizontal surface of nodes one can connect to, while not allowing anyone to see all nodes in play to reduce the impact of DDoS attacks. (If using PNN, one should never connect to any specific node and always ask PNN for a node address each time a connection is made).

Your own node is fine as well, but depending on the underlying hardware and bandwidth constraints, it can crumble above 1k client connections. If an application is popular, it can experience a few thousand client connections, which can tax the node quite heavily. Anyone can setup their own PNN cluster, but I encourage people to use PNN and contribute their nodes to PNN. This pattern helps everyone.

[ASPECT @CryptoAspect]

Heya. In some areas, you are correct, in some ...not quite.

I can’t do an in-depth response to this post as it would require an even larger post :) So I’ll just focus on what I consider to be key elements.

1) vProgs paper is really just a set of guidelines. It has been reviewed in detail by me and the developers working with me. It has a number of issues, but nothing a team can’t solve within a day in front of the whiteboard. The key pillar (CDAG structure) is solid (but its implementation is very complex).

2) The way vProgs are designed is that they are basically the same as on-chain SCs. If properly done, the UX would be indistinguishable from traditional high-performance smart-contract-capable chains. (but vProgs bring numerous superior capabilities that TBH wipe the floor with all existing tech).

3) vProgs are absolutely possible and feasible - we have been doing R&D in this domain for 1.5 years now, and I have absolutely no red flags.

4) Adoption-wise, vProgs are just like any other SC system - all they need is a well-harmonized SDK with a bunch of primitives. I am trying to steer the design toward zkVM framework neutrality, which increases the project complexity, but for good reasons.

5) The economics of different system layers are actually well understood by some of the people involved. There is, however, no published material on the subject. Typically, this is addressed once you have a PoC.

6) There is a “one size fits all” solution, and that’s vProgs. It is important to understand that vProgs is a ZK composability layer that turns Kaspa from a global sequencer into a global ZK sequencer - without imposing any limitations or obstructing anything.

7) I have recently published a document called vProgs JAM SESSIONS on the TG R&D channel ( https://t.co/XWP8hvNdmO and https://t.co/zAqtYFQc8H ). This document is meant as a "soft bridge" between the R&D performed by my team (Sparkle) and the Kaspa vProg research team. While the document identifies various subjects and poses suggestions, most of them are well understood and, in many cases, have been prototyped on our end ✨.

So none of the questions you are raising (specifically) in relation to vProgs are my concern.

The REAL problems are the team communication, project management, and the lack of a holistic software architecture (which I am attempting to solve). This is further aggravated by the lack of properly structured funding and ad-hoc attempts by different developers to tackle the challenge.

There is currently “no one in charge”. There are a number of developers “developing”, but no one gave guidance with respect to what they should be developing. It is literally a group of construction workers making a building without any architectural plans. Build a sky-scraper, they said, …and everyone is trying to make one.

The problem is the fact that the complexity of the project and layers involved are extremely multidisciplinary, and this is not something that a single developer can construct (neither, as a developer, would I be able to). In my recent comms with @michaelsuttonil I’ve stated that in fact the complexity of this is comparable to KIP-1. It’s a very large and complex project. However, if properly executed, with concise and _coordinated_ efforts, an MVP can be achieved within 6-8 months. (note "coordinated" being bold, italics, and underlined).

I am currently trying to steer @hashdag toward a proper project execution structure based on the clearly defined architecture. I have huge respect toward @michaelsuttonil, @hus_qy, @FreshAir08, @Max143672, and everyone else working on this, so I can’t just “barge in” and start telling everyone what to do. I can guide and coordinate everyone, but only if they align behind the effort and adopt the architecture I am proposing.

So, at this point, I have helped the team to identify key stress points and problems related to ZK (that took us months to understand), and gave a tentative architectural blueprint to the team that is meant to envelop the vProgs Yellow Paper design. I have suggested to @hashdag that we schedule a few weeks of in-person R&D meetings in front of a whiteboard to solidify the architecture, understand everyone’s proficiencies, understand what code and subsystems already exist and can be reused …and execute.

[ASPECT @CryptoAspect]

@xximpod Sure, I’ll join in.

[ASPECT @CryptoAspect]

The interesting thing about this design, is that technically, it does not require another “layer” per se. There will be a general purpose layer, for simplicity and ease of use, but it’s important to outline that you can have “many vProgs on a layer” OR each vProg “can be a layer.”.

There is a specific emphasis on state vs proof separation.

One can simultaneously publish a “smart contract” and give others access to it, or develop in-house standalone application (think Kasia) that uses vProg interface to communicate across its instances globally while retaining and managing/transfering Kaspa (tokens, or any data) in a provable way without any PKI.

1) technically, you can supply your own state when invoking vProgs

2) vProg can be a completely isolated separate (even private/hidden) app monitoring L1 and posting proofs of its actions

meaning you can supply your state, you can also execute your own vProg (it doesn’t matter where state or vProg comes from).

3) vProgs (being ZK programs) themselves have infinite scale as you can have a HUGE external app proving its actions where vProg can also function like an “action proxy” by verifying one or multiple external proofs and taking actions based on these proofs (this part is more akin to traditional SCs capable of ZK verification).

(can == should be able to, as all of this is currently designs and prototyping)

These are very unique and important factors that need to be understood. (and actually quite hard to explain and even harder to implement because developers are biased toward concrete “tangible” software implementations whereas this implementation is more akin to a “layer as a decentralized global API/Interface/Methodology” that anyone can make/use/instantiate).

So the “L2 layer” in this case, can be “any observer” watching L1, taking actions and posting proofs of execution to L1 synchronizing itself. This is in part what “program sovereignty” and “sovereignty as a service” refers to.

The only other thing L1 offers is basically a protocol (transaction structure) that tells the external vProg “interpreter” “how” it should manage state access - which state can be accessed asynchronously (reads) vs which state access needs to be sequenced (writes).

…all that without impacting performance and decentralization properties of L1.

[ASPECT @CryptoAspect]

Execution/processing occurs only on L2. L1 knows nothing about state but it also knows nothing about programs or transactions. In a way, L1 is agnostic to L2 transactions (albeit protocol conformance, program IDs and mass might be handled at L1 layer in a supervisory/delegator capacity. i.e. unlike a full pass-through that takes place for an indexer, there might be some additional logic/sanity checks). but in any case, L1 primarily functions as a sequencing carrier. Hence you cant aggregate multiple transactions and have L1 interpret them.

So yeah, we should drop any notion of rollups.

However (this part is not defined in the vProgs paper yet, but there are known mechanisms for this) ultimately vProgs will be able to move Kaspa among themselves. L2 transactions can facilitate multiple such transfers, which then can be projected back onto the UTXO set. So in that sense, one could describe this as compounding multiple transfers via vProgs. ..but it’s a different animal.

[ASPECT @CryptoAspect]

That’s not correct. vProgs are original, so is Sparkle L2. They achieve same goals (ZK program composability) but in different ways at the core level. Sparkle L2 data processing might not be applicable or match design goals of vProgs.

A term like “technology transfer” should be used with caution. I specifically said “lessons learned”, “research” and “solutions to various challenges”. So at best it is “technology sharing”.

Unlike vProgs, Sparkle L2 does not have same program sovereignty considerations and its CDAG approach is completely different. Sparkle design uses pure ZK-recursion-driven CDAG (it uses ZK composability to maintain and compress CDAG) whereas vProgs use consensus style processing where CDAG related commitments become integral to consensus. Sparkle L2 would require minor modifications to consensus just to address few vulnerabilities (but require compute for CDAG maintenance), whereas vProgs relies on heavier modifications of L1 (and less compute).

So like I said they are similar, achieve similar goals, but inherently different. The main focus where vProgs can benefit from Sparkle L2 is at the protocol and ZK program execution and composability approaches.

[ASPECT @CryptoAspect]

@ReLeomerda @DesheShai TBD

[ASPECT @CryptoAspect]

In essence vProgs design is very similar to Sparkle L2 design. Not the same, but very similar. I’ve been gradually transferring our Sparkle L2 “lessons learned” to vProgs researchers on TG R&D channel. There are still a number of subjects and designs to compare and brainstorm on (in various areas we are far ahead with our in-house efforts and in some areas we have achieved similar goals using different approaches).

Given similar goals, I’ve decided that in the interest of the ecosystem harmonization, the best strategical approach will be to consolidate everything under the vProgs umbrella in an effort to help accelerate vProgs design and development. I am currently in talks with @hashdag and am actively helping to address various challenges that we have already identified and solved. So to that extent, one can say that vProgs will have a significant boost thanks to the efforts made on the Sparkle L2 project.

[ASPECT @CryptoAspect]

These designs are pending as this subject is not currently defined in the Yellow Paper. Technically vProgs should be able to manage resource/account-associated Kaspa deposits, but this requires additional designs and I don’t know what the research team will settle on. I (myself personally) think vProgs should be able to manage resource/account deposits interchangeable with UTXOs as well as asynchronously interop with existing UTXOs.

[ASPECT @CryptoAspect]

@ReLeomerda @DesheShai IMO it should be an optional module within the Rusty Kaspa daemon.

[ASPECT @CryptoAspect]

I believe I have originally coined a term “L-1.5” in an effort to describe a hybrid system where the separation of responsibilities is such that parts of the system exist in L1 and parts of the system exist in L2 (or rather in a closely L1-mated secondary network)

If you simply do everything in L2, the layer becomes exposed to a set of very complex vulnerabilities. Partially merging the processing logic gives best of both worlds - keeps L1 “thin” while allowing it to safely offload unlimited scalable decentralized compute into a separate network/subsystem. Hence L-1.5 :)

[ASPECT @CryptoAspect]

@JackKHash @DesheShai @ReLeomerda also, technically, there is no need to do any UTXO associated processing. a CDAG driven by L1 consensus can be completely independent from the UTXO set as it is driven by L1 transactions and thus stays in sync with L1 consensus. …but that’s a whole different subject.