I don't think there is a classic money reward, but you will have other kind of reward/benefit.
I think you should run your own node if you created some service relying over stellar network.
This way you will connect to your horizon instead of using other service.
Furthermore you can configure your server to accept query only from your services.
Won't be able to tell exact number, but this is not an issue.
Stellar has different levels of participation. Only archiver and full validator nodes publish archive and maintain full history.
Also this archive doesn't need to be stored on the server, it can be published to S3 bucket or any other cloud storage.
Nodes keep current state of the network and ...
We will be redesigning the Nodes section of the Dashboard really soon so it's very likely that the "verified node" will be gone.
The reason we added a "verified node" badge was that we wanted to list both:
the companies we work with (like IBM)
nodes run by developers from our community (we often don't know outside our Slack).
By adding a special badge to ...
If you look at the stellar dashboard there's a list of validators. You will see names like FairX, IBM, Tempo, SatoshiPay, StellarPort etc. These are all businesses that are invested in the success of Stellar. Since it's very cheap to run a validator (it's comparable to running an email server) you don't need big incentives to become one. Just an interest in ...
As some have noted in other answers, there is no direct monetary incentive in maintaining a node. This isn't necessarily bad news: if you look at Bitcoin's proof-of-work - and especially at how it became centralised over time - then it makes some sense NOT to have a monetary incentive, and thus avoid the problems it can cause.
Last time I started the full sync on my server (dedicated i7, 64 RAM, SSD), it took around 2 days to complete. It was about a month ago, with Stellar Core v9.1.0 and Horizon v0.12.1.
With earlier versions before Stellar Core v9, the full sync process usually took more than 10 days to complete on my environment.
When CATCHUP_COMPLETE=true option set, ...
The SQL database can be thought of as a simplified view of the ledger state stored in the bucket list. As such the only data that stellar core relies on is account based not transaction based.
Now there are a couple tables (txhistory and txfee) that contain transactions and their related metadata for the purpose of being exported to Horizon.
As you can ...
An archiver node is a special kind of node:
when it sees a quorum (based on other basic/full validators on the network), it publishes to an archive.
Publishing is done every 64 ledgers if it's in sync with the network. You can read more about this in the history documentation
A shared db definitely makes a lot of sense for most production deployments, if you have access to RDS then it has some very convenient features, it takes care of backups, offers point in time recovery and if using HA you get a standby master too...
As well as using shared databases, you will want to run your Horizon and Core deployments on multiple servers ...
Yes you are correct: when a validator is only observing consensus it will emit this warning.
In your case the reason it’s only observing consensus is that your node is still catching up to the network. As it doesn’t have the current version of the ledger it cannot validate transactions that it sees.
As soon as the validator is fully caught up this should ...
Yes, you are right that a full validator configures and writes to an archive. But basic validator can also have a history archive.
Apart from all other differences mentioned in the documentation, main difference between Full and Basic validator is that, full validator maintaines full history archive and publishes it for anyone to view. Its publicly ...
You can read the network configuration section in the admin guide.
Here is the relevant snippet:
For a new value to be adopted, the same level of consensus between nodes needs to be reached as for transaction sets.
What that means is that the mechanism (consensus) to get the network to agree to a change is the same one than for deciding which transaction ...
The docs specify the hardware requirements, quoting (as off 5/7/2018):
Instances of Stellar-Core are part of the network as a
node and therefore need to be large enough to support the volume on
CPU: 4-Core (8-Thread) Intel i7/Xeon or equivalent (c5.xlarge
RAM: 8GB DDR4
There is no clear cut specifications.
Note that stellar core requires 64bit OS. If your small machine can afford running 64 bit, it should be more than powerful enough and there is no problem.
Update 2018 Nov:
Over 250GB storage used, for full-sync public network which has been up for several years.
Note that the projected usage is likely ...
Thanks to Bartek's advice, I no longer encounter this error. I made our own Stellar Horizon Docker image with horizon-v0.12.3.
The level=warning msg="ingest: waiting for stellar-core sync error I brought up in our (Bartek and me) exchange of replies in the comment section is different from this question and is not related with this question.
What you probably saw is the result of DDoS countermeasures in the Stellar network (we’re working to make this less aggressive while preserving safety): the way to test that a validator is working (or simply to use it) is done by adding that validator’s ip & port to your “preferred peers” setting (or at a minimum to a validator that you know is connected ...
Yes, you should create a stellar keypair and define it in your stellar-core.cfg
You have to provide a history archive, here is a snippet from the example stellar-core.cfg:
# Note: any archive you *put* to you must run `$ stellar-core --newhist <historyarchive>`
# once before you start.
# for ...
I have solved this and sharing in case anyone runs in to the same problem:
My node was validating the ledgers as the logs were showing, HOWEVER, the port I was using was closed. Hence, it was not reachable from outside. A simple nmap scan will show you if your node is reachable on the given port or not.
From the docs:
If you don’t include a NODE_SEED or set NODE_IS_VALIDATOR=true, you will still watch SCP and see all the data in the network but will not send validation messages.
Does that help?
Q1 & Q3 are similar
better refer to this answer
"you should run your own node if you created some service relying over stellar network"
For instance, if you are relying on an external Horizon and once it is hacked or down, your service could be doomed. You have better control over your own Stellar node.
Yes, and you may find out more about ...
A couple things.
First, the way quorum sets are configured are always done in the context of a validator.
A validator will never “vote” for something it doesn’t agree with so when you have things like “AB+CD” in the context of A it just means that C and D’s votes won’t matter for A (unless B somehow depends on them).
Second, you need a property called “...
I could fix this error on my end. Basically, I had to:
Stop Core and Horizon servers
Connect to the local postgres and delete the stellar and horizon databases
Delete the contents of /var/lib/stellar/buckets
Recreate the databases with stellar-core --newdb and stellar-horizon db init
Start again the services
My configuration is a bit different as I used ...
This output basically tells you that curl could not download the file.
[Process WARNING] process 26047 exited 22: curl -sf http://history.stellar.or...
The process exited with a 22 code. That code is documented here alongside all other error codes: https://curl.haxx.se/libcurl/c/libcurl-errors.html
This is returned if ...
When you started up your horizon endpoint, you specified (I hope :) ) a stellar-core for it to connect to, via the "--stellar-core-url" flag or "STELLAR_CORE_URL" env variable:
Your configuration for stellar-core, however, is what defines how you want your node to ...
Currently, all client apps I am aware of are hard-coded to use one specific horizon or allows to switch between one public network horizon and one testnet horizon. It is up to client app developers to disclose it to users. Likewise, the same is about a feature to select a specific horizon.
Each Horizon is tied to a specific node to where it submits ...