Recently, there has been a lot of discussion around the topic of ANO and server management. That was a stumbling block for me when I started tinkering with Factomd since the code responsible for on-boarding ANOs happens to spread across different repos. This blog aims to shine some light on the whole situation, detailing what exactly Inc. does when they “onboard” and “deboard” servers, how interested parties could launch their own custom network, and a few other maintenance utilities.
This blog is aimed at developers and other technically inclined people. I tried to keep it as simple as I could so everyone can follow along but fully detailing all the concepts like cryptographic signatures would result in … Read the rest
One of the hurdles that we frequently run into when developing is the question: “did this actually improve the product?” This can lead to some very interesting discussions about where the actual bottleneck is. One of the ways is to have a specific test harness that will perform the same actions in a predictable environment. If the data improves after changes are made, you can demonstrate that it has improved.
So I ended up making a test harness for the network. Some of the questions I had going into this test was:
Is my P2P2 library an improvement over the old library?
Does it make sense to make it more efficient if the limiting factor is the network?
Currently, onboarding and deboarding of authority nodes is done by whoever has access to the network skeleton key. That key is hardcoded in the factomd codebase. Whoever has access to the private key essentially controls the authority set. There are a number of drawbacks to this approach:
The private key can be held by multiple parties without any accounting of who uses it. Party A signing a message is identical to Party B signing the message, with no way to know who sent it. The only publicly known party to hold the private key at the moment is Factom Inc.
It can’t be revoked. Should an employee with access to the private key part with the company, or should
One of PegNet’s selling points is decentralization — officially there is nobody in charge of PegNet. It works as long as the people using it agrees to play by the same rules, which at the moment is done by everyone using the same software: pegnetd. As a core developer for pegnetd, one of the first questions I ask myself before considering a new feature is: how will the community react to this?
That immediately raises another question: Who exactly is the “PegNet” community and can we determine who the majority is? The obvious answer is that it’s a combination of all the people using it: members on discord, core developers, exchanges, miners, etc., however, it’s not feasible to … Read the rest
As of block 222270, PegNet switched from using the bootstrap formula for the value of PEG to using the market value, calculated from the three exchanges that list the token: CiteX, ViteX, and VineX. For miners to be able to oraclize this data, we needed to add APIs to the system. Every asset in PegNet has at least two separate APIs to pull data from and we did not want to make an exception for PEG. CoinGecko was the only existing API for the price of PEG, so two entities in the PegNet community stepped up: Factoshi and Factomizewith the goal of being phased out as other data aggregators come online.. The APIs of Factoshi and … Read the rest
Update (Nov. 6th, 2019): A new version of the PegNet Daemon has been released that lets you burn FCT by typing pegnetd burn [source address] [amount] .
It’s Monday, October 7th and today we are launching the most important aspect of PegNet: Transfers and Conversions or, in short, Transactions. They will be enabled starting with block 213237, with a planned official launch at 15:00 UTC.
What was once just an idea and a whitepaper is now reality. We are happy to release the PegNet Daemon, which will extend PegNet’s functionality to include these additional features:
Transfering any pegged asset to a different address (e.g. sending 10 pUSD to another person)
Converting pegged assets (excluding PEG) to a different
Can’t believe it’s already one year since I started working for Factomize. At the time, I only had a superficial knowledge of blockchains and no experience writing Golang. David’s charge to have me become a Factom Protocol core developer seemed like an almost insurmountable task.
At first, I just worked on the Factomize forum, which was more in line with my area of expertise, while getting familiar with the Factom community and node. A couple of months later it was time to learn Golang and familiarize myself with the core code. My first pull request was on January 7th, 2019, simply adding myself to the factomd CLA. That was followed by my first feature implementation: adding https support to the … Read the rest
Over the past couple of weeks, I’ve been involved in the PegNet project and I wanted to share my understanding of what it is and how it works with the rest of the world. I’m a developer and not an economist, so my perspective focuses more on the technical aspects than how to master the market. Due to the large scope of the project, this blog will be split into multiple pieces, with the first one focusing on the Oracle.
PegNet, short for Pegged Network, is a set of tokens pegged to existing currencies. It is built as a Factom Asset Token (“FAT”) standard on top of the Factom Protocol, meaning that the values and transactions sit inside … Read the rest
In my previous blog post on the gossip network, I detailed how the current network has a tendency to form a hub network and how that introduces both inefficiencies and scalability problems. A short recap: when booting up, all nodes connect to the seed nodes, leaving them with a disproportionally vast connection count. This impacts the fanout of messages with the seed nodes receiving a disproportionate amount of messages, the duplicates of which are dropped.
The ideal network structure is every node in the system connected to an equal amount of other nodes. This is made difficult by the fact that nodes are not aware of the network topology.