[ANN][XEL] Elastic Project - The Decentralized Supercomputer

[CyanFox]

XEL is almost ready, glad to see the news, we investors wait so patiently, we finally will get paid. No doubt that the project is gonna moon.

[1714770880]

1714770880

[1714770880]

1714770880

[1714770880]

1714770880

[1714770880]

1714770880

[1714770880]

1714770880

[tomkat]

@EK last week in your roadmap, do you have any updates for us?

Whole package arrives as promised on weekend, including a full documentation and in fully operable state.
The roadmap was reorganized a bit, but (from my side) everything went (and goes) as planned.

So no more testnet before mainnet launch ?

regards

I doubt there will be single start point for the mainnet. I think a testnet will be formed by (new version) nodes initially, and then depending on the network state (no bugs), users will start redeeming their stakes slowly.

[bspus]

I doubt there will be single start point for the mainnet. I think a testnet will be formed by (new version) nodes initially, and then depending on the network state (no bugs), users will start redeeming their stakes slowly.

So the best testnet will become a de facto mainnet? Is that a good idea?

[Bgjjj2016]

I doubt there will be single start point for the mainnet. I think a testnet will be formed by (new version) nodes initially, and then depending on the network state (no bugs), users will start redeeming their stakes slowly.

So the best testnet will become a de facto mainnet? Is that a good idea?

These are all speculations until we hear from EK.

[tomkat]

I doubt there will be single start point for the mainnet. I think a testnet will be formed by (new version) nodes initially, and then depending on the network state (no bugs), users will start redeeming their stakes slowly.

So the best testnet will become a de facto mainnet? Is that a good idea?

That's how I understand EK's proposal to allow users to launch the mainnet by simply start using the system.
Don't know if it's good or bad, but there will be bugs after that for sure. I think we just need to make sure there're no major flaws, and the system works as expected.
Also, nobody has seen supernodes and guardnodes yet, so we'll need to test it too before going "live".

[Bgjjj2016]

I doubt there will be single start point for the mainnet. I think a testnet will be formed by (new version) nodes initially, and then depending on the network state (no bugs), users will start redeeming their stakes slowly.

So the best testnet will become a de facto mainnet? Is that a good idea?

That's how I understand EK's proposal to allow users to launch the mainnet by simply start using the system.
Don't know if it's good or bad, but there will be bugs after that for sure. I think we just need to make sure there're no major flaws, and the system works as expected.
Also, nobody has seen supernodes and guardnodes yet, so we'll need to test it too before going "live".

Your explanation makes sense. Thank you !

[techwriterjoe]

 I suppose you could think of it as a "public beta release"? There probably isn't a better way to test than to get some actual users.

[Evil-Knievel]

Also, we need to set a strategy what to do when no supernodes are available (nor registered in the system). Just verify all work instantly? Block any work from being done? Or don't care about it al all?

All the little details have to be sorted out now ;-)

[coralreefer]

Also, we need to set a strategy what to do when no supernodes are available (nor registered in the system). Just verify all work instantly? Block any work from being done? Or don't care about it al all?

All the little details have to be sorted out now ;-)

My vote would be that the supernodes are required for any ElasticPL processing (of course, wallets would still work fine w/o SNs).  But in the least I don't think we should allow any new work to be submitted if there are no SNs.

[Evil-Knievel]

Also, we need to set a strategy what to do when no supernodes are available (nor registered in the system). Just verify all work instantly? Block any work from being done? Or don't care about it al all?

All the little details have to be sorted out now ;-)

My vote would be that the supernodes are required for any ElasticPL processing (of course, wallets would still work fine w/o SNs).  But in the least I don't think we should allow any new work to be submitted if there are no SNs.

That was also my initial guess ;-)

[coralreefer]

Also, we need to set a strategy what to do when no supernodes are available (nor registered in the system). Just verify all work instantly? Block any work from being done? Or don't care about it al all?

All the little details have to be sorted out now ;-)

My vote would be that the supernodes are required for any ElasticPL processing (of course, wallets would still work fine w/o SNs).  But in the least I don't think we should allow any new work to be submitted if there are no SNs.

That was also my initial guess ;-)

EK, can you clarify something about the SNs, which may help make this decision...my understanding is that we went to the SN approach to offload the ElasticPL validation from the core server for a couple reasons, the main ones being:

  1) The time it takes to validate the submissions from multiple jobs (even small ones) could impact the performance of the core server if done there
  2) Using SNs would allow us to increase the memory available to ElasticPL jobs

If either or both of these are the case, I would think SNs are required for ElasticPL processing.

[Evil-Knievel]

Also, we need to set a strategy what to do when no supernodes are available (nor registered in the system). Just verify all work instantly? Block any work from being done? Or don't care about it al all?

All the little details have to be sorted out now ;-)

My vote would be that the supernodes are required for any ElasticPL processing (of course, wallets would still work fine w/o SNs).  But in the least I don't think we should allow any new work to be submitted if there are no SNs.

That was also my initial guess ;-)

EK, can you clarify something about the SNs, which may help make this decision...my understanding is that we went to the SN approach to offload the ElasticPL validation from the core server for a couple reasons, the main ones being:

  1) The time it takes to validate the submissions from multiple jobs (even small ones) could impact the performance of the core server if done there
  2) Using SNs would allow us to increase the memory available to ElasticPL jobs

If either or both of these are the case, I would think SNs are required for ElasticPL processing.

Yeah, the main reason was to have more ram and to support a higher WCET (how high, we still have to specify). Otherwise, we would have to limit the available resources to what we expect the weakest nodes in the network to have.

Nice side effect, no matter how crippled the ElasticPL language is, it can never halt the network. This can be also seen as: no code is executed anywhere else than on guard nodes and super nodes - worth to mention to those, who are potentially afraid of this since they want to run Elastic on critical systems such as exchange servers.

[tomkat]

I must say I'm not big fan of the idea of supernodes and guardnodes.
Why? Because we're to build decentralized supercomputer, and those new node types will probably make the computations centralized.

Few reasons that I can think of now:
-300k XEL collateral will most likely be not possible for an average user

-new attack vectors against supernodes, or against network.
Examples: (1) supernode owner can switch it off purposely just to cut off someone (or whole network, if it's the only supernode) from computations, (2) supernodes can be attacked (DDoSed for instance) just because their owners are rich, or the network relies on them, etc.

-no incentive for "ordinary" users to run nodes, ie. why should I run the node if there's no supernode in the network

-is it possible supernodes will be cheating? what is exactly a procedure of seizing the collateral in case supernode is assumed to be malicious? what if the procedure will be used to eliminate someone from the network?

-introducing supernodes and guardnodes makes the ecosystem much more complex


Also, do we know anyone interested to run supernode at launch?
If not, then we can expect no supernodes, unless developers will run one.

[Limx Dev]

I must say I'm not big fan of the idea of supernodes and guardnodes.
Why? Because we're to build decentralized supercomputer, and those new node types will probably make the computations centralized.

Few reasons that I can think of now:
-300k XEL collateral will most likely be not possible for an average user

-new attack vectors against supernodes, or against network.
Examples: (1) supernode owner can switch it off purposely just to cut off someone (or whole network, if it's the only supernode) from computations, (2) supernodes can be attacked (DDoSed for instance) just because their owners are rich, or the network relies on them, etc.

-no incentive for "ordinary" users to run nodes, ie. why should I run the node if there's no supernode in the network

-is it possible supernodes will be cheating? what is exactly a procedure of seizing the collateral in case supernode is assumed to be malicious? what if the procedure will be used to eliminate someone from the network?

-introducing supernodes and guardnodes makes the ecosystem much more complex


Also, do we know anyone interested to run supernode at launch?
If not, then we can expect no supernodes, unless developers will run one.

I think 300K is okay. You can start with 100Mio Xel ~333 Server.

[ttookk]

Well, how many 300k contributors do we have at the start of the mainnet? And how many of them are willing to run a supernode?

In general, I think supernodes are a good idea and 300k is ok as collateral, but maybe there should be a starting period of X blocks, in which supernodes require less collateral, to get people started? Maybe the required collateral should start at, let's say 50k and rise gradually, until it reaches 300k. Or is that a stupid idea?

[Limx Dev]

Well, how many 300k contributors do we have at the start of the mainnet? And how many of them are willing to run a supernode?

In general, I think supernodes are a good idea and 300k is ok as collateral, but maybe there should be a starting period of X blocks, in which supernodes require less collateral, to get people started? Maybe the required collateral should start at, let's say 50k and rise gradually, until it reaches 300k. Or is that a stupid idea?

I think that is possible but we have currently 86 ico members with more than 300K XEL.
https://dl.dropboxusercontent.com/u/21000833/Elastic/Icolist/Ico-list.txt

[hagie]

Well, how many 300k contributors do we have at the start of the mainnet? And how many of them are willing to run a supernode?

In general, I think supernodes are a good idea and 300k is ok as collateral, but maybe there should be a starting period of X blocks, in which supernodes require less collateral, to get people started? Maybe the required collateral should start at, let's say 50k and rise gradually, until it reaches 300k. Or is that a stupid idea?

I think that is possible but we have currently 86 ico members with more than 300K XEL.
https://dl.dropboxusercontent.com/u/21000833/Elastic/Icolist/Ico-list.txt

Uhh looks like I missed the 300K collateral thing. Too bad I really want to run a supernode beside the public node. Is the collateral for the guardnode the same ?

Time to look for partners to get the needed amount of xel :-)

regards

[tomkat]

Well, how many 300k contributors do we have at the start of the mainnet? And how many of them are willing to run a supernode?

In general, I think supernodes are a good idea and 300k is ok as collateral, but maybe there should be a starting period of X blocks, in which supernodes require less collateral, to get people started? Maybe the required collateral should start at, let's say 50k and rise gradually, until it reaches 300k. Or is that a stupid idea?

Progressive collateral would be good if we're listed on exchange (so you could buy some), or there're jobs for which supernode owner could get XEL.
It's rather unlikely to start getting XEL immediately after launch

[tomkat]

Also, we need to set a strategy what to do when no supernodes are available (nor registered in the system). Just verify all work instantly? Block any work from being done? Or don't care about it al all?

All the little details have to be sorted out now ;-)

My vote would be that the supernodes are required for any ElasticPL processing (of course, wallets would still work fine w/o SNs).  But in the least I don't think we should allow any new work to be submitted if there are no SNs.

That was also my initial guess ;-)

EK, can you clarify something about the SNs, which may help make this decision...my understanding is that we went to the SN approach to offload the ElasticPL validation from the core server for a couple reasons, the main ones being:

  1) The time it takes to validate the submissions from multiple jobs (even small ones) could impact the performance of the core server if done there
  2) Using SNs would allow us to increase the memory available to ElasticPL jobs

If either or both of these are the case, I would think SNs are required for ElasticPL processing.

Yeah, the main reason was to have more ram and to support a higher WCET (how high, we still have to specify). Otherwise, we would have to limit the available resources to what we expect the weakest nodes in the network to have.

Nice side effect, no matter how crippled the ElasticPL language is, it can never halt the network. This can be also seen as: no code is executed anywhere else than on guard nodes and super nodes - worth to mention to those, who are potentially afraid of this since they want to run Elastic on critical systems such as exchange servers.

Is it possible that a job can exceed resources available on the weakest supernode?
Will the configuration required for supernode be enough for all jobs?

[mladen00]

Well, how many 300k contributors do we have at the start of the mainnet? And how many of them are willing to run a supernode?

In general, I think supernodes are a good idea and 300k is ok as collateral, but maybe there should be a starting period of X blocks, in which supernodes require less collateral, to get people started? Maybe the required collateral should start at, let's say 50k and rise gradually, until it reaches 300k. Or is that a stupid idea?

I think that is possible but we have currently 86 ico members with more than 300K XEL.
https://dl.dropboxusercontent.com/u/21000833/Elastic/Icolist/Ico-list.txt

there are more investors with +300k
86 ico members are having +300k with only one (single) transaction