Topic: Fully Decentralized Scaling Solution (Read 383 times)

Unlocked to reply to @achow101, blog has been updated to include a technical overview. Thread has been locked again as I am focusing on the business side of things on the project and do not want to get to caught up in convo. PM me if you have any questions.

P.S Flow has just made my day, validating that our MVP the Sub-Zero Protocol is right in the money.

https://medium.com/@scroda/3-projects-that-aim-to-surpass-the-blockchain-trilemma-d774da02994c


Unlocking this thread, looking for further discussion.

Stop right here lock this thread spend your spare time in finding investment partners, angels or silent investors.

Work on the project, make sure you have a good MVP or prototype and get someone on board that can fund your adventure.

The community is disarrayed right now on this forum and a thread like this will not help you much with promotion as it might not ever pick up. And you are not at a point where you can run promotions.

You should get a CMO and/or a Crowdfunding guru who'll be just as important as your CTO.

Once you have the basics down, you can get into incubators but remember, doing so would make them your puppetmasters. Just take a look at some of the crypto projects from Y Combinator.

If you need my help, DM me. I'll come back with questions when you share some tech info.

Good luck.

Let me work on it and it should be my next reply, I will get all the technical aspects down, I usually post the basics first just to have a date on the material as I go along. Been pretty busy with some other stuff and will make time go a bit more technical into it.


The website is Scroda.io

The company is registered in St Kitts & Nevis

Whitepaper is there as @achow101 suggested I will work on getting a more technical paper out explaining how leaders are elected, and how transactions move from chain to chain technically.

Right now we are trying to move forward with development and funding, I have a CTO on board whom was a core developer of Digibytes, still we at the same time need funding to move forward, having day jobs we really can't afford to go full time on the project right now.

Could you actually post some technical details about how it actually works? Something that someone could use to implement their own software?

As it stands, this is just a whole lot of marketing mumbo jumbo with no details as to how it works which means that there can be no evaluation of whether this is actually decentralized or not. Just because you say it is decentralized doesn't actually make it decentralized.

Chill your tits.

Stay focused. You will come across many trashy comments and even worthless ones, just learn to deal with them tactfully.

I know I can't keep calm in most situations and that has resulted me in lashing out against idiots, but I advise people to not cave in to that kinda silliness.

Returning to topic.

You call yourself the CEO, good. So it must mean the project is already off the grounds. So which stage is it in right now? What have you done and who's working on it?

Let's get the basics out of the way first. Where is the company registered? Have you got a website yet? Have you got a whitepaper and techpaper jotted down?

I do not get why I come across so many people like you on this forum, all talk about staying true to satoshis decentralization and fully supportive of decentralization and then you come out and say that you would rather stick with a federated sidechain, so you are okay with a member of 30 or so organizations being able to hold your coin hostage if needed? Liquid's federation makes the security provided by Bitcoin's POW useless. When will I stop coming across such trash comments.

You provide nothing useful in your comment and then come out to say you will stick with federation.  



This does nothing to increase scalability, time is still going to be taken to communicate with all nodes who vote with each other, would not work alone.  

OP, thanks. I'll stick to the proven Bitcoin POW/blockchain, and the federated Liquid Network sidechain combination. But you should develop it, and make an altcoin out of your idea, good luck.

I think , adding votings to a unconfirmed transaction is a solution .
How it works --

1. Someone broadcast a transaction (maybe with tag like dynamic transaction) to p2p network .

2. Each node receiving the transaction see if it’s a valid transaction (say by applying AcceptToMempol/AcceptableInput),

    2a. If successful (Transaction is fully valid ) , give upvote(with some sort of signature )
 
    2b. If failed (Transaction is not good) , do nothing or give downvote

3. Now, Network count the votes,
   
    3a. If upvotes - downvotes >= certain amount of votes (say 100, i.e. upvotes - downvotes >= 100);
          then assume transaction is valid and can be spent, (with proof that it has enough upvotes )
    3b. If downvotes > upvotes ,
          then transaction is not valid and should not be submitted to miners.

4. A transaction having enough upvotes submitted to miners (that in 3a)

CEO, also you can see it as a trade-in each chains has its benefits, still the bad the centralization does not affect the good the security, as the bad is greatly restricted, only allow leaders to establish a order of events, they have no say so in which transaction is true or not.

The only bad they could do is maliciously say B came first than A no benefit is gained from such act, also in a system where leaders are changing in sub-second time no affect would be seen from say a leader not reporting or failing to report.

Yes reaching instant transactions poses its threat, this is reaching consensus instantly, a decentralized network needs time to act, The more nodes there are the more time it takes for them to communicate, this is why centralized networks are much faster at acting since they do not have to share information around with others. In a network where nodes are receiving information from other nodes it would generally be impossible for all this activity to be done instantly, unless there was some form of centralization. A fully decentralized network will always suffer from the time taken to communicate with others to be able to act accordingly as a whole. Trying to reach consensus instantly on a fully decentralized network would be foolish as there would not be enough time for all nodes to communicate with each other thus not failing to obtain the security from decentralizing a network, in the end failing to be decentralized.

Either way would be open to discuss more if anyone has any red signs they are seeing would love to dwelve into it.

So basically its a trade-in. Some centralization and some decentralization. May I ask what your affiliation to Scroda is?

And you suggest that instant transactions pose a security threat, can you technically elaborate that so people that are more experienced in the subject than I can review whether what you are saying holds its grounds?

These days we are used to seeing a solution first problem last approach when it comes to the development of new techs and platforms. It's just something people are used to. Don't take it personally.

So I have been trying to get opinions from members of the community regarding a new scaling solution in which some users have been neglecting to read just because of the wording used in the title, so this time I will try a different approach explain the solution first and then word it last.

• It is fully decentralized, consensus is reached by all available nodes.
• It is secure, all the time that is needed in order for data to fully propagate will be used.
• It is scalable, achieved by a rotating leader solely establishing an order of events.

• It is not centralized, the rotating leader does not verify/validate transactions at all, only set a paper trail of order of events.
• It is not semi-centralized, there is no committee/delegates verifying/validating transactions.

The Sub-Zero Protocol permits Scroda to achieve Sub-Second Zero-Confirmation Transactions all due to two chains coming together and becoming one, Yin and Yang.

Blockchains to this day verify transactions on a block to block basis thus allowing for attacks such as the reversal of transactions through a 51% attack. The harmonization of both chains working together to process transactions enables Scroda to obtain security while allowing for it to scale. The use of relay chains, the establishment of an order-of-events, and the verification of transactions on a transaction to transaction basis before permanently being placed on the Scroda main chain allows for zero-confirmation transactions in sub-second time.



Yin is the chain in which is centralized; the bad in blockchain, while still showing properties in which are good for its users; its ability to scale. The yin chain solely focuses on establishing an order of events, through the use of a rotating leader, moving away from approaches seen in competitors in which utilize a committee.



Yang is the chain which is decentralized thus providing security, the good in blockchain; sluggish, a property in which is bad for its users. The yang chain focuses on verifying transactions after an order of event has been established on the yin chain, having a trail to now follow. This trail allows for all nodes on the Scroda platform to verify transactions together and reach consensus on a transaction to transaction basis before being placed on the mainchain; offering a fork free environment.



Focused on security, Zero-Confirmation Transactions allows a receiver to solely verify a transaction and have the guarantee that it will be processed if true, all before consensus has been reached.

Instant Transactions become a bit trickier as the idea is that consensus is reached on the blockchain instantly the moment a transaction has been broadcasted. Due to security concerns reaching consensus instantly for transaction is not feasible nor advisable

Zero-Confirmation Transactions do not disrupt the time needed for data to propagate between nodes thus not interrupting the time needed for consensus to securely be reached.

https://medium.com/@scroda/scrodas-sub-zero-protocol-walkthrough-c1677f3d60fa