Robots at Recruitment

The digital revolution in society had its starting point with the emergence of the personal computer in the early 1980s. The second step that impacted society was the commercial exploitation of the Internet and the creation of the World Wide Web by Tim Berners-Lee. Jumping a couple of decades to the present days, we are now witnessing the rapid success of Robotics thanks to the current stage of Artificial Intelligence (AI).

Several companies are trying to automate human tasks using robots, defending fewer mistakes in repetitive tasks. The detractors support that fewer jobs will be available. Regardless of the opinion of the defenders and detractors, we are witnessing in our daily life­ social collaboration with robots.

Currently, there is a debate about the impacts that robotics is making to society. The labor market is one side that is completely changing. In terms of social robots, there is a novelty coming from two companies in Sweden – Furhat Robotics and Tengai AB­.

Figure 1: Furhat Robot

A new company called Furhat Robotics has been developing social robots that can be used as the first frontline for any interaction process with humans. The robots are composed of a face mask, where inner light projects all the facial movements. The combination of the light beam and the mask cover creates the illusion that the face, lips, and eyes are moving.

The hardware plus the software creates a social robot that can be used in several social interactions. The robots have been used as a concierge in the airport [1]; as a teaching assistant to engage students [2]; as a pre-screening medical robot to detect signs of the world’s common diseases [3]; and as a recruiter to remove bias from the hiring process [4].

Figure 2: Tengai is the word's first unbiased social interview robot. Here with Elin Öberg Mårtenzon, Chief Executive Officer at Tengai and Chief Innovation Officer at TNG.

Tengai AB is a company that offers unbiased recruitment using robots called Tengai Unbiased. With Tengai robots, the recruitment process can be transparent, data-driven, and anonymous. All the applicants will follow the same interview procedures, making it data-driven.

Elin Oberg Martenzon is the forefront of Tengai AB and assured that soft skills and personality traits could also be screened by adjusting the interview process according to different role descriptions.

The recruiter can easily prepare Tengai robots for the interview using Tengai software to manage and overview the process. The interview is fully automated and has an integration with a self-service booking for the candidate.

Besides their national customers, Tengai also aims international customers, and they will launch an English-speaking robot at the beginning of 2020. “The interest of this product has been massive, and it is now possible to sign up on the waiting list to get your Tengai as some of the first companies in the world.” – says, Elin.

In the early stages, these, robots are helping hiring managers in doing the first interview process, but, with the current stage of AI, these robots, most likely, will be able to perform the most of the hiring process.

We see Tengai AB at the forefront of the future recruitment process, and one potential customer segment will be the international staffing and recruitment industry. So robots are here to help.

[1] https://www.furhatrobotics.com/press-releases/robot-concierge-trial-germany-japan/

[2] https://www.furhatrobotics.com/customer-stories/stockholms-stad/

[3] https://www.furhatrobotics.com/customer-stories/merck/

[4] https://www.tengai-unbiased.com/

From Blockchain to Hashgraph

Blockchain is a decentralized, distributed and public digital ledger that uses hundred of computers to prove that something, e.g., a transaction or a record, actually happened. Blockchain is a transparent and living digital document of collecting and verifying records.

Blockchain uses smart contracts to incentivize the usage of technology. Smart contracts permit trusted transactions and agreements to be carried out among different, anonymous parties without the need for a central authority, legal system, or external enforcement mechanism. The transactions are traceable, transparent, and irreversible.

In the past, only official entities could verify transactions; nevertheless, the verification process was not transparent, and it could be corrupted easily.
This novel technology has a significant impact on society, and it is turning into a philosophical opening in how we re-arrange society and business.
Several companies, like Maersk or Open, use Blockchain to improve the efficiency of their business.

Maersk manages circa 150 ports around the world, where vessels are continuing deploying containers. One challenging point for the company is to track the containers.

For deploying a container, a vessel requires coordination with several companies and lots of documentation to track the shipment between two ports. By adopting blockchain technology, Maersk achieved with the help of smart contracts, full control over the container interactions while reducing the correspondent operational costs by 10%-15%.

Another company, Open – the first end to end logistic supply platform for commodities (rice, grain, oil, gas, metal), had difficulty in tackling topics around fraud, corruption, and price manipulation, mainly because transactions were not transparent. Again, with the use of smart contracts, this company improved the efficiency of its operations. An end to end logistic process that would originally take weeks to happen would now happen in minutes, while at the same time reducing the number of intermediaries, and, ultimately, cutting the product selling price.

In terms of social impact, Blockchain can be a useful technology for casting, tracking and counting votes. Although there are detractors about the use of this technology for replacing the traditional ballot box due to vulnerabilities, it is true that Blockchain has what is necessary to eliminate voter fraud.
Blockchain voting startups are working to overcome this skepticism. Maybe in the future Blockchain or alternative technology could make this scenario a reality.

There are different types of Blockchain implementations with different properties, as well as, alternative technologies.

One technology that is gaining hype and it is gaining the support of prominent groups is Hashgraph. Groups like Deutsche Telekom and Swisscom have been backing up Hashgraph. As a result, it is expectable that the market will adopt this technology to some extent.

Hedera Hashgraph

Hashgraph is a decentralized, distributed and public ledger that uses hundreds of computers to register and validate transactions. It is considered an alternative to Blockchain, one which tries to tackle the limitations of the technology concerning performance, fairness, cost, and security. There are not many Blockchain applications that can do five transactions per second. In contrast, Hashgraph can do a hundred thousand transactions per second.

Hedera is a company co-founded by Leemon Baird and has the goal to build a trusted and secure digital future. Hedera is governed by a council composed of corporations and organizations from different sectors. Hashgraph offers smart contracts, micro-storage, decentralized storage, and allows micro-transactions.

However, what makes Hashgraph different from Blockchain?

Hashgraph is a patented algorithm that has its data structure and achieves good results of scalability and performance due to two techniques: gossip of gossip and virtual voting.

The gossip of gossips technique broadcasts messages through an existing network of pre-authorized nodes. In Hashgraph, only hosts can read and write to the database and must have a database that is immune Sybil and DDoS attacks.

A Sybil attack occurs when an attacker is hit most of the time by creating several different accounts. As a result, the attacker can approve such transactions as triggering a double expense problem. For Bitcoin, this problem was solved through the work test.

In turn, Hedera what the results were pre-approved by them, are not considered valid or are of interest like no Blockchain.

Hedera Hashgraph is a probabilistic algorithm, that is, a non-deterministic algorithm. As such, it may not be able to reach the odds of being hit, nor the messages that are exchanged, how long does it take to reach a consensus.

Consensus is expected to be reached as time passes.

Structure level, the Block is a blockchain, which comes each block has a hash of its transactions and a pointer to itself and to the previous block. In contrast, Hashgraph stores the projects that are connected in a direct acyclic graph. In Hashgraph, each event contains two pointers for different parents.

We can see in the image below a distinction between a Blockchain event and Hashgraph. The event contains two hashes that point to the parent, a timestamp and a list of transactions. In Blockchain, the indexer in each block contains the address and content of the previous block.

The consensus algorithm in Hashgraph is not proof-of-work or proof-of-stake. It is an asynchronous Byzantine Fault-Tolerant algorithm that is resistant to DDoS and Sybil attacks.

Hashgraph Example

In this example, we have five different nodes in this Hashgraph. Each member starts by creating an event which is a small data structure in memory. Then the community is going to run a gossip protocol. E.g., Bob is going to send all the event that Ed does not know, yet. This could be a single transaction that Bob has made. Ed records the transaction by creating a new event which is the new circle in the image. Now Bob has a connection with Ed. Both Bob and Ed have two connections (From Bob to Bob, and from Bob to Ed. And from Ed to Ed and Ed to Bob). The new connections are represented in the hashes that the new event contains.

We can see in the image below that a Hashgraph event contains two hashes that point to the parent, a timestamp and a list of transactions.

Blockchain vs Hashgraph Event

Then, Ed sends all these events to Carol, and Carol sends the events to Bob. This exchange of events propagates the data. Moreover, because the events contain hashes, it is called Hashgraph. Each event contains the hashes from the previous events, and its creator digitally signs it.

Hashgraph has the notion of round. Hashgraphs contains witnesses that will vote on the validity of the transaction. The first event on each round for a single node will be called a witness. When we have all the witnesses, we have to see if it is a famous witness. A famous witness is one that is used multiple times.

Famous witnesses are chosen in an election. This is done considering the witnesses in the next round. A witness is deemed to be famous if it is seen by many of the witnesses in the next round. To determine if it is a famous witness, all witnesses must vote for it.

The goal of the election is to determine how often a transaction has passed all the nodes. If it is valid, it has been passed a lot. So, the longer the transaction is maintained in the hashgraph, the more trusted it can be.

Hedera is the public version of Hashgraph in the works. It will be governed by a council of leading corporations and organizations across multiple industries, and it will use this council as a Proof of Work to prevent Sybil attacks. Hedera claims to achive four main objectives: to provide smart contracts, micro storage, decentralized storage, and its own cryptocurrency allowing microtransactions.

There are several differences between Blockchain and Hashgraph. Blockchain ensures that data is not stored at a single location, while Hashgraph is a distributed ledger that works on the data structure with a distributed consensus algorithm.

The Hashgraph does not require Proof of Work, and can also deliver low-cost and high performance without a single point of failure. Also, Hashgraph does not need high computation power.

Hashgraph allows hundreds of thousands of transactions per second. In contrast, technologies that use Blockchain have different speed in terms of transactions per second. Bitcoin can make 7-10 transactions in a second, Ethereum has potential to perform 15-20 transactions per second, and Hyperledger can make thousands of transactions in a second.

Hashgraph also proves to be fairer than Blockchain as miners can choose the order of transactions, can delay them or even stop them from entering the block if necessary. However, in Hashgraph, a consensus of a timestamp is used preventing individuals from changing the order of transactions.

Hashgraph is a promising technology, but it also comes with some limitations.

Currently, the technology has only been deployed in private and permission-based network. It is still to be tested and explored in the public network. In gossip of gossips technique, when a node passes information to another node, there are chances that the closest nodes are malicious which may prevent the passage of information to other nodes.

The technology behind the Hedera Hashgraph is exceptionally intriguing, but its real potential and effectiveness are promising.

Byzantine Fault Tolerance, from Theory to Reality

Many people connected to the computer business in several distinct roles (programmers, architects, and many more) don't know the concept of Byzantine failures. If there's someone who has heard this term once, most likely forgot the term immediately.

In the most general sense, Byzantine failures are defined as arbitrary deviations of a process due to any anomaly. The term "any" really means any fault (permanent or occasional) that occurred in the software or the hardware. This type of faults are pivotal in a distributed systems world and are often neglected when creating systems, or when debugging them. This clear unrecognition makes this topic confined to the academy or singular projects.

Let's separate the concepts of Byzantine faults and failures because I will use them interchangeably.

1. Byzantine faults: a fault presenting different symptoms to different observers.
2. Byzantine failure: the loss of a system service due to a Byzantine fault.

This paper from Driscoll et al. revisits the Byzantine problem from the practitioner's perspective and alerts everyone that this type of faults should not be neglected.

The term Byzantine failure was proposed a long time ago by Leslie Lamport et al. (The Byzantine Generals Problem). They present the scenario of a group of General divisions that surround an enemy camp. The Generals must communicate to each other to agree on a plan of action -- whether attack or retreat. If they all attack at the same time, they will win. If they retreat, they will live another day. If just part of the division attack, then the generals will die.

This sounds like an easy problem, but in fact, all generals are surrounding the enemy, and they can only communicate with each other using the messenger. The messenger can be killed or replaced by the enemy, or the enemy can change the message. Moreover, some generals may be traitors and send inconsistent messages to disrupt loyal generals from reaching consensus.

The Lamport paper discusses the problem in the context of oral messages and written signed messages. Regarding oral messages, it has been proven that to tolerate f traitorous generals, it is necessary 3f+1 generals and f+1 rounds of information exchanged. If it is used signed messages to prove authenticity from the senders, it is possible to reduce the number to 2f+1 generals and f+1 rounds of information exchange.

Consensus is an integrated part of a Byzantine fault tolerant system. Addressing the consensus problem at the protocol level reduces the software complexity, but leaves the protocol itself vulnerable to Byzantine failures.

The common use of COTS components increases the probability of a system to suffer a Byzantine fault. Good hardware is not also sufficient! Small electric perturbations in the components can guide the hardware to a have a 1/2 input. For example, the CPU suffered a perturbation in the voltage and emitted a bit that it is not possible to know if it was a 0 or 1. Back-propagation can even amplify the error, and the whole system can fail. Moreover, this error can become permanent, and the system will never achieve a correct state.

This paper presents a Time-Triggered Architecture (TTA) as a generic architecture for fault-tolerant distributed real-time systems. This architecture is targeted to the automative industry where communication requisites are high. This architecture implements a deterministic fault-tolerant communication protocol (TTP/C) that guarantees synchronization and deterministic message communication. This service provides membership service to allow a global consensus on message distribution and can tolerate this type of faults as long as the errors are transient. By radiating components with ions, was sufficient to introduce faults in the components. This careful design resulted in the introduction of centralized filtering to remove invalid signals (e.g., 1/2 signal) into valid logic signals.

This papers also presents a Multi-Microprocessor Flight Control System (MMFCS) that was developed in the '70s. This system introduced the concept of self-checking pairs and used a dual self-checking pair bus distribution topology. The self-checking pair comparisons of processors, bus transmission and reception enabled a precise detection of Byzantine faults. The MMFCS observations concluded that Byzantine faults are not as rare as we can suppose. They can run permanently or intermittently. A misconception is to assume that random events are uniformly distributed in time. In reality, the precipitating conditions can make a fault persist. Similarly, it is a myth that Byzantine faults won't propagate to other components. In the worst case scenario, a Byzantine fault can shut down the whole system.

Effective methods for dealing with Byzantine faults can be divided into three types: full exchange, hierarchical exchange, and filtering topologies. These methods can be used in conjunction or separately. The first method implements the exchanges described in the Lamport paper. The second method uses private exchanges inside subsets of a system's node followed by simplified exchanges between the subsets. The third method tries to remove Byzantine faults via filtering. The paper presents examples of implementation of these three methods. Although these examples are implemented in the hardware, there are also other software solutions.

In overall, Byzantine faults are very real, and nowadays the use of COTS components make this type of faults even more severe. It is very hard or impossible to design a Byzantine fault tolerant system without consensus. Consequently, the term "Byzantine faults" should be in the head of every software and hardware engineer, and this paper gives credible examples. In my personal view, I hope that companies that produce hardware and software start to include this topic in their plans.

[1] Byzantine Fault Tolerance, from Theory to Reality, K. Driscoll, B. Hall, et. al, Computer Safety, Reliability, and Security
[2] The Byzantine Generals Problem, L. Lamport, R. Shostak, M. Pease, ACM