Topic: [ANN][XEL] Elastic Project - The Decentralized Supercomputer - page 237. (Read 450523 times)

2 month AFTER testnet runs stable

When it's ready

2 months

When will Elastic be released? The 1st page has no information, and I'm getting errors on the webpage.

You've got a point regarding the "keeping miners on Elastic" issue. As I wrote before, I think the solution is based on the amount of work we expect on the Elastic network.
A possible solution that was mentioned before was essentially turning the Elastic network into a mining pool for cryptocurrencies other than XEL. So when no jobs are to be solved, the miners mine other coins instead, until a job is submitted. I suspect this only works for smaller voids, though.

Also, I just throw out the "last resort" option.  If we really can't solve for keeping miners around when there are few to no work packages, maybe we should just go the other extreme and get rid of POW.  Miners get paid the same when no package is available...nothing.  When I comment POW out of my code, the ElasticPL parser runs great.  It just seems that there is a need for a lot of overhead on the POW piece to ensure mining is fair.  Honestly, if I was mining a package at this point I would just turn off the POW myself even if we decide to keep it.

I guess I've come around to your original comments that the bounty reward is what will really draw miners.

@ek: still getting "Could not validate unsigned bytes returned by the server." when I try to update my account info on testnet :-(

regards

No too bad not. Most of the technical / calculation stuff posted here looks to me like magic language from Hogwarts ..

I'm only good for running nodes / wallets and server stuff which I'm doing in my spare time like : https://steemit.com/howto/@hagie/multiwallet-delegate-server-lisk-rise-dlisk-using-reverse-proxy-from-scratch-on-debian8

regards

I didn't mean to imply getting rid of POS.  What I was trying to solve for is that, regardless of reputation, efficiency, etc, we need a way to encourage miners to be on the network and readily available for when work packages are submitted.  It won't do the work owner much good if he submits the first package in a week and no POW miners are on the network...his work will just stagnate.

So I was trying to think of a way to keep miners on the network while also solving the POW efficiency issue.  I threw out letting the miners share in the fees with the POS miners, but realize there are lots of issues there as well (i.e. wrong algo and we get into the asic wars and still don't have miners for work package).

I'm just coming at this from a different angle than most.  One of building up a pool of miners ready for work packages.

Hi, You also xel's dev? Hagie. Good job.

Hi all,

the public testnetnode at https://elastic.cryptnodes.site/index.html is updated to the latest git.

sorry for the delay.

regards

Maybe we can make this more efficient here ;-)

SHA256 can hash with a rate of 169.49 MB/s (according to numerous benchmarks presented in sources like this one). 64012 Integers are roughly 256KB. So my computer is limited to 169.49 / 0.25 ~ 677 evaluations for any elastic program in the best case ... likely less.

So, this sucks big time!

EDIT: My calculation sucks somehow ... even any 3rd class Bitcoin CPU miner can make several million SHA256 hashes (https://en.bitcoin.it/wiki/Non-specialized_hardware_comparison#Intel) per second. Maybe it's really just the implementation?? Sidenote: If you ever need to find out the real MB/s speed of SHA256, never consult any of the sources you find using your favorite search engine ... they are simply wrong

I think we need to come up with an alternative scheme to verify that "work has been done" in terms of "hashes that meet a certain target are submitted".


What's wrong with POS? Does it really matter from the tech point of view if POW or POS is used for block mining,? Isn't it that the only difference is that while the first choice wastes energy and the second doesn't? ElasticPL itself was never involved in block mining.

ElasticPL mining is done using transaction's only ... no ElasticPL miner can create a "block" just submit a "claim" transaction to get his reward.

I'd like to elaborate on my thoughts on a reputation system, so, here it is:

As stated before, a negative reputation system wouldn't work, because miners can simply change identities. A positive reputation system needs to have ways to let new miners enter the system and shouldn't be mandatory in the first place.
Nevertheless, any reputation system will create a barrier to new miners, which might cause a problem, because if the miners are not sufficiently rewarded for their efforts, they won't bother mining XEL, which leads to less computing power, leading to less jobs, leading to lower XEL prices, and so on, turning into a diabolic downward spiral.

That being said, here are my thoughts on the reputation system. I welcome criticism and suggestions:

I'll use a simplified scenario. Let's assume we have 100 XEl in the system, 5 miners(Miner01, Miner02 and so on) and 5 wallets, containing different amounts of XEL:

Wallet(05):5 XEL
Wallet(15):15 XEL
Wallet(20):20 XEL
Wallet(25):25 XEL
Wallet(35):35 XEL

Every wallet can only vote for a maximum number of miners, in this cenario, let's assume 2 (in reality, I think a numbe rbetween 25-50 is appropriate).

The miners register as miners and try to collect votes. They can do so by using the most common channels, XEL will have, be it a dedicated forum, twitter or whatever.

The wallets can vote all the time. They can change their mind as well and vote for other miners, but voting will cost them a small fee. Every X blocks (probably a timeframe that would be around a week IRL), a snapshot is made in which is checked,
- Which wallet voted for which miners (The last vote sent in counts)
- How much XEL is held in the wallets which voted.

The amount of approval a wallet can give to a miner is equal to the XEL it holds at the time of the snapshot. The whole weight counts for every miner, the wallet voted for, therefore, voting for a smaller number of miners than possible has no direct advantage.

In our scenario, it could look like this:

Wallet(05): Miner01, Miner02
Wallet(15): Miner01, Miner02
Wallet(20): Miner02, Miner03
Wallet(25): Miner03, Miner04
Wallet(35): Miner03, miner05

This would give our miners these amounts of approval:

Miner01: 20
Miner02: 40
Miner03: 80
Miner04: 25
Miner05: 35

Job authors may now decide to set a minimum amount of approval for their jobs, because they fear an attack. Let's say, they set the amount at 30. This would mean, only Miner02, Miner03 and Miner05 are allowed to work on the job.
Here, we can see a problem this system still has: There is a chance that the holder of Wallet(35) and Miner05 are the same person and have malicious intent.

I'd still like to combine this solution with the option of using a whitelist, in which specific miners are listed. This whitelist wouldn't be Elastic-wide, of course, but it would be created by the job author.

In this scenario, Miners will probably build pools and conglomerates to collectively vote for one mining identity. I'm not sure what to think about this, but I have the feeling that this is not our business. In the end, it might even be positive to XEL, because there pools have good reason to stay on the good side.

Happy to hear your thoughts on that matter. I'm not exactly in love with this idea and would like to hear other solutions.

The would compete for the same fees as POS mining as well Work Fees when available.

Since the amount of XEL is fixed, the miners would mine air if there are no jobs, though…

I see the same performance issues in my C miner, so it's not just java.  This is the issue I've been raising for a while that running ElasticPL is very inefficient...almost all effort is in the sha256 hashing.  I was thinking that you were hashing the 64012 integers so that the miner proved they actually ran the ElasticPL code.  If you get rid of it, how do you prove the miner actually ran the ElasticPL code and didn't just throw random numbers into the memory?

As I mentioned before, I really see the best solution as having POW participate in the block mining rather than ElasticPL...that way miners are always there regardless of whether or not there are Work Packages.  Then when Work Packages are there, they do both POW and ElasticPL submitting the bounties as currently designed.

The whole identity business is true and I don't think there is going to be a clean solution. that's why I came up with the idea to implement a voting system similar to Lisk(I'll explain the lisk voting system a little further at the bottom):


I mean, a blacklist wouldn't work, but a non-mandatory whitelist would, if it was well-maintained by a trusted source (although this would probably be a kind of hidden centralization).

More thoughts on that matter, especially in regards to Lisks system:


To explain Lisks voting system a little further: Every wallet which contains LSK(or XEL…) has a voting weight equal to the XEL it contains. To vote with a wallet for a miner, a special transaction is made, which requires a small fee. the miner is now essentially "approved by this wallet", the "amount" of approval is based on the weight of the wallet. This can change obviously depending on tokens getting in or out of the wallet, so it is checked regularly. In Lisks system, the 101 delegates with the highest "approval" are allowed to forge Lisk. In Elastics network, there wouldn't be such a hard cap in place, instead a job author can decide to set a minimum amount of approval.
To ensure some kind of "job security" and to keep the overhead low, I'd modify the voting system in a way, in which there is only one voting every week.

This would mitigate the issues at hand in two ways:
- A miner wouldn't want to spread out over different identities, because they would have to get voted for multiple times.
- Am miner could still buy XEL and vote for themselves, but ideally, this would be extremely expensive, and the Elastic community could enforce voting of other miners to raise the minimum amount of approval over the level of the attacker.

I admit that this is far from being a clean solution, but it's something

The POW checks significantly slows down the mining process.
The reason is that 64000 integers are hashed after every iteration of the program in order to obtain the PoW hash so it can be checked against the target value.

Without the PoW check we have 50.000 evaluations per second using the (just updated) miner for a simple 5 line arithmetic program.
With the PoW check we drop as low as 600 evaluations per second.

Same with the personalizedIntStream, which uses SHA256 to obtain deterministic input numbers .

Any idea? Should we move from SHA256 for the PoW hash after all? Or is it just the shitty java implementation?
What do you think?

My thoughts on this:

- In order to know how long a program will execute (this is needed for our difficulty retargeting mechanism), it's required to perform a worst case execution time (WCET) analysis. A WCET execution analysis on programs written in traditional programming languages such as C, Java, Python or OpenCL is hard to achieve, if not impossible. The reason for example are loops (which cannot be estimated how often they will be run unless actually executing the program, and then the iteration count can depend on other factors such as the input itself).

- In the common case you can allocate as much memory as you like … this can cause out of memory errors on less potent hardware while going through on good hardware → the network can be split by shooting down certain nodes keeping alive others.

- Ususally, it is possible to create programs that will run forever and you cannot decide that beforehand for the project to reject such software (it's basically the halting problem). This could turn all nodes into a heavy, hot paperweight.

- Programs written in other programming languages can crash (division by zero, null pointer exception, etc.) and can be used to attack the network.

This, and some other reasons, require the creation of a new language where the above problems do not occur in the first place. Our language does not crash, it always terminates, the run time can be estimated beforehand and you can only use a limited amount of memory allowing us to give minimal system requirements where we can guarantee that every program will execute successfully if a machine matches those system requirements.

I have added this to http://elastic-project.com/elasticpl


You can transform any ElasticPL program to an equivalent OpenCL program, it's just not the case vice versa.

@akhavr,ttook: The problem with rating schemes is imho that you can create an infinite number of alternative identities, all with a clear background. Reputation may work in centralized systems that require some sort of authentication like e.g. eBay, but if we do not want to penalize new users without any rating, we will have a hard time coming up with a reputation system that really works. I mean I could rip off some workers, collect negative reputation, move the XEL to a fresh account and start over.

What do you think?