Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a chapter about physical location #3

Open
wants to merge 8 commits into
base: master
Choose a base branch
from
Open

Add a chapter about physical location #3

wants to merge 8 commits into from

Conversation

ruuda
Copy link
Contributor

@ruuda ruuda commented Oct 9, 2024

Background

As a company we often receive RFIs that include a question about location, and we often get questions from potential clients about location. I usually push back on that question because it is not well specified and can be interpreted in many ways, and a specific answer will go out of date quickly anyway, but I’m tired of having to explain this every time.

That’s why I wrote this chapter, so we can have one standard answer to point people to when the topic comes up again. My goal for this is:

  • Explain why there isn’t always a clear location where “it” runs.
  • Explain what goes into picking a location:
    • In order to clarify that the optimal location varies over time.
    • In order to clarify that restrictions on region make our life harder and they should only be a last resort.
  • Explain that even if we give a concrete answer, it will go out of date quickly.

If this chapter doesn’t answer people’s specific question, I included three possible interpretations of “where does it run” at the end of the chapter. We can use this to ask for clarification if people need a more concrete answer to check the box.

Note to reviewers

  • The handbook and this repository are public! Keep in mind that any review comments are public, please don’t put super specific details in here and definitely no confidential information.
  • Keep in mind that this is an approximation, everything depends. I tried to strike a balance between explaining the nuance and having a document that people might reasonably read; we don’t have space to include the full technical details and subtleties of every network we operate.

This question comes up so often. I want to have a document that explains
why the question is wrong, and why the answer if you ask it anwyay is
"it's complicated" and "it depends" and "that's not really what you want
to know, is it?".
This adds the section with answers to what I guess most companies that
send us RFIs want to know. (Or well, I don't know what they really want
to *know*, but these are my intepretations of the questions they send).
@@ -0,0 +1,497 @@
# Physical location

We often get asked “Where do your validators run?”

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

0/5

Suggested change
We often get asked “Where do your validators run?”
We often get asked “Where do your nodes run?”

Copy link

@Szymongib Szymongib left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, just few typos or superficial/opinionated comments 👍

Comment on lines +24 to +48
Software consists of computer programs that get executed by a chip.
In our case,
that chip is inside a server,
which is in a rack,
which is in a building,
which is part of a data center facility.
That facility has a clear physical location.
It’s located in a country, and it has an address.
We can say that the program is running in that particular location.

Blockchains are _distributed systems_.
They don’t consist of a single program running on a single machine,
they are emergent systems that arise
from many instances of a program interacting with each other.
These instances can run on different machines,
in different physical locations.
While a particular instance has a well-defined location,
we can’t really answer the question of “where” the blockchain network is,
more specifically than “everywhere where people run nodes”,
which might be as broad as “everywhere on Earth”.[^1]

A blockchain network as a whole does not have a clearly defined location then,
but at Chorus One we don’t operate the entire blockchain network,
we operate validators that are _part_ of the network.
Don’t these validators at least have a clearly defined location?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to go to such details? Since it is a part of "Network Handbook", I would assume readers familiarity with basic blockchain concepts. I am fine leaving it in if you think it can be useful in cases of less technical people.

Comment on lines +64 to +65
[^1]: Probably except for Antarctica.
Antarctica doesn’t have a very stable high-bandwidth Internet connection.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Running in the middle of the ocean might be challenging as well if we want to be that specific 😉

Comment on lines +426 to +428
This means that the location of our validator identity
will generally move around between locations,
sometimes multiple times per day.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This means that the location of our validator identity
will generally move around between locations,
sometimes multiple times per day.
This means that the location of our validator identity
can move around between locations,
sometimes multiple times per day.

and in a city several thousand kilomaters away the next.

The details of the failover process
(and whether we can do this at all)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

0/5

Suggested change
(and whether we can do this at all)
(and whether it is possible)

when hardware reaches the end of its lifespan,
its replacement will not necessarily be in the same location.
* **The set of peers changes, and peers move.**
We more our workloads around, and so do other node operators.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
We more our workloads around, and so do other node operators.
We move our workloads around, and so do other node operators.

Comment on lines +396 to +401
The details vary from network to network,
but typically one instance will be actively validating
(participating in consensus and proposing blocks).
Other nodes download and validate a copy of the chain,
so they are ready to take over validator duties at any time,
but they are not participating in consensus or proposing blocks.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The details vary from network to network,
but typically one instance will be actively validating
(participating in consensus and proposing blocks).
Other nodes download and validate a copy of the chain,
so they are ready to take over validator duties at any time,
but they are not participating in consensus or proposing blocks.
The details vary from network to network,
but typically one instance will be actively validating
(participating in consensus and proposing blocks),
while other nodes download and validate a copy of the chain,
so they are ready to take over validator duties at any time,
but they are not participating in consensus or proposing blocks.

but spreading our infrastructure brings challenges of its own.
As we observed before,
distributed systems tend to become slower and less stable
when they are spead out further.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
when they are spead out further.
when they are spread out further.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants