Hey everyone and welcome to today's Protocol Lab Research Seminar. Today we are joined by Shorbeck Deb. Shorbeck is currently a second year PhD student at the University of Washington in the Department of Electrical and Computer Engineering. Previously he worked as an industrial researcher at NEC Corporation in Japan working on the state-of-the-art signal processing modules for 5G technology. Before that he graduated from the Indian Institute of Technology in Bombay with a dual-degree bachelor's and master's in electrical engineering and completeness thesis on Frugal 5G. And today he's going to be talking to us about his work titled OSAT, Proof of Work Availability and Unpredictability Without the Work. So Shorbeck, I'm going to hand it over to you and away we go. Thank you for the introduction, thanks everyone for coming to this talk. So today I'll be talking about OSAT, which is the first provably secure proof of state blockchain protocol that achieves both dynamic availability and unpredictability. This is a joint work with my advisor, Professor Sriram Kandan from University of Washington, Seattle, and Professor David Stee from Stanford University. Here will be the flow of the talk. So we'll first go through the introduction to the problem that we try to solve in this work. Then we'll go to the protocol description of the OSAT and then we finally will understand the proof behind the security of the OSAT. Before going to the OSAT, let us understand what are the key features of Bitcoin that we try to emulate into the proof of state protocol. So Bitcoin achieves three key properties. It is secure under honest majority while guaranteeing dynamic availability and unpredictability. The question that we ask in this work is that can one design a proof of state protocol that can also achieve all these three properties or not. So before answering this question, let us understand dynamic availability and unpredictability in the context of Bitcoin and the existing proof of state protocol. Dynamic availability in Bitcoin can be best understood from the evolution of Bitcoin's total hash rate since its conception. This total hash rate that comprises of both honest and adversarial computational power in the system at any time has seen a 14 orders of magnitude change since its inception. As an indicator of its dynamic availability, the Bitcoin protocol has been continuously adding transaction to the ledger for the past 11 or 12 years. The main characteristic about Bitcoin guaranteeing dynamic availability is that it remains secure under honest majority. To be precise, consider that in the first year of the operation of the Bitcoin, all of the nodes in the system are honest. Consequently, the system evolves to give this snapshot of blockchain at the end of the first year. At the beginning of the second year, the adversary joins the system. Although the resulting adversarial hash rate is less than the honest adversarial hash rate in the second year, the second year adversarial hash rate is much higher than the first year honest hash rate. Now what the adversary can do is that it can try to rewrite history by going back in time and mining blocks for the time when it was not online and in order to overwhelm the existing public canonical chain. However, in Bitcoin, the probability of mining block is directly proportional to the computational power. So the canonical chain also evolves in that time and so the adversary will never be able to rewrite the history and able to catch up with the canonical chain. Thus, it is safe for Bitcoin to guarantee dynamic availability to all nodes to be able to join the system irrespective of whether that node is honest or adversarial. Now the question we ask is that whether a proof-of-stake protocol can also guarantee the same or not. Let us first see how existing proof-of-stake protocols try to answer it. In the context of dynamic availability in proof-of-stake protocols, the sleepy model of consensus like sleepy model of consensus of snow, white and auroboral genesis, they have used longest chain protocol in an attempt to guarantee dynamic availability. However, without careful design, the longest chain protocols in proof-of-stake are vulnerable to costless simulation attacks. Let us see how this costless simulation attack works. Similar as before, consider that the adversary joins the network in the beginning of the second year. And although the adversarial stake is less than the honest stake in the second year, the second-year adversarial stake is still higher than the first-year honest stake. Now the adversary can use its second-year stake to almost instantaneously participate in the past lottery to win blocks all the way back to the genesis and then grow a chain there from the genesis that surpasses the current longest chain. So this is possible in proof-of-stake protocol because there is no notion of arrow of time in proof-of-stake protocol. In contrasting Bitcoin, each node had to do some computational work to propose blocks and that imbued a notion of arrow of time in the system. So due to the absence of this notion of arrow of time in proof-of-stake protocols, this costless simulation attack is possible wherein a newly joined node not only increased the current adversarial stake but effectively increased the past online adversarial stake as well. I'd like to point out that even using verifiable random function is not enough to get a different against this kind of costless simulation attack. So sleepy model of consensus and autoborals genesis have sidestepped this attack by assuming that the adversarial stake is constant while honest stake can vary. In context of Bitcoin, this will be akin to assuming that the adversarial mining power is fixed at genesis. There's a question of whether a proof-of-stake protocol can guarantee dynamic availability just like in Bitcoin or not is left unanswered. As for unpredictability in Bitcoin, due to proof-of-work mining, no node including itself can predict when a node will be able to mine a block. For illustration, consider this blockchain in the Bitcoin. In Bitcoin, for mining the next block, a node has to keep trying different non-tests until the proof-of-work puzzle is satisfied. However, the node does not know when will it satisfy the puzzle. Neither does some adversarial node can predict when this node will be able to mine a block. Only after the node finally satisfies the puzzle does everyone know that the node has been able to mine a block. Thus, the Bitcoin mining process is totally unpredictable. For proof-of-stake protocol, commenting about unpredictability is a bit more complicated. If a nice proof-of-stake puzzle like hash function is used for determining the winner of the lottery, then everyone can predict who wins when. This makes the system vulnerable to bribery attacks. On the other hand, if more sophisticated puzzles like a verifiable random function is used as consistent with many of these papers, then no one can predict who wins except the winner itself. However, now an adversarial node can advertise its prospects of winning in the future lotteries in some black market. The Bitcoin-like unpredictability is still elusive in proof-of-stake protocols. The main contribution of our work is that we present POSET, the first proof-of-stake protocols that guarantee both proof-of-work style dynamic availability and proof-of-work style unpredictability while being provably secure under honest majority. Let's go through the protocol description of this one. In order to achieve dynamic availability and unpredictability in POSET, we use verifiable delay functions for conducting the lottery. So what is this verifiable delay function or VDF as it's called in short? It's a tuple of three functions, the setup function, the eval function and the verify function. There are two key properties that motivated us to consider VDF for the purpose of conducting the leader election. Computing eval function of VDF even with parallel processes takes at best linear time and no less than that. However, the verification of the work done in computing the eval function can be done blazingly fast in polylevel. With these two properties, it ensures that the VDF computation is not costlessly computable. It gives an unpredictable randomness decal. Now let us see how POSET uses this VDF. For this, let us first recall the proof-of-work mining in Bitcoin. Consider this blockchain. Suppose a new node at the tip of the blockchain is received at a node. Under proof-of-work, a node will select a nonce at random. This nonce will be used to check whether the proof-of-work puzzle is satisfied or not. If no, then a node will select another nonce at random. If yes, if the proof-of-work puzzle is satisfied, then the node is able to append a block at the tip of the blockchain. In POSET, instead of proof-of-work puzzle, we use a VDF puzzle that is constructed from the eval function of the VDF. Now when a block is received, a non-source of randomness ran-source is extracted from the block and check whether the VDF puzzle is difficultly satisfied or not for this updated ran-source. If the POSET puzzle is not satisfied, then the updated ran-source is sent again to the VDF puzzle. If yes, then the block is proposed and the updated ran-source is embedded in that block. The actual eval function of VDF that is used in conducting the lottery to propose the next block follows this iterative template. To summarize, in POSET, for conducting the lottery to propose a block, the randomness embedded in the parent block is used as the source of randomness. In order to propose the first block after the genesis, the node will use the randomness RLG embedded in the genesis block to compute the eval function and a winner will embed the updated randomness RS1 into that block. Similarly, for proposing the second block, the nodes will use the randomness RS1 embedded in the block 1 to compute the eval function for proposing block 2 and so on. However, this block-by-block update of a source of randomness gives an adversary many more random chances, independent random chances, to increase the growth rate of the private adversarial chain. To concrete this intuition, consider an adversary that is trying to create a longer private fork from the genesis. As each block offers an independent source of randomness and due to nothing at stake phenomenon, the adversary will grind on all the blocks from the public canonical chain by the parallel execution of multiple verifiable delay functions. So as expected, the growth rate of the longest chain is directly proportional to the honest state. However, the growth rate of the adversarial tree, instead of being just proportional to the adversarial state, it is amplified by a factor E. So extrapolating this nothing at stake attack that leverages this block-by-block update of randomness, the adversary can grow trees on all blocks in the honest chain, with each of them having an amplification factor E on their growth rate. For the adversarial trees that are far from the tip of the longest chain, they are less likely to catch up with the public canonical chain. But the trees that are close by, they are more likely to catch up due to randomness. So this looks scary as it seems like that the adversary would always succeed in this private adversarial attack. However, the good news is that for adversarial stake fraction beta less than 1 by 1 plus E, if one waits for a sufficiently long time, one can find this special green block in the longest chain such that with high probability, no adversarial tree starting from any of its ancestral blocks would be able to catch up with the longest chain containing this green block. Thus going forward, this green block will always be present in the prefix of the longest chain. Such a phenomenon is called as convergence in the literature. So for adversarial stake fraction beta less than 1 by 1 plus E, with block-by-block update of source of randomness, poset is secured against private attack. However, bitcoin is secured against private attack for all beta less than half. So as we are trying to replicate the properties of bitcoin in proof of stake, the obvious question would be whether we can push the security threshold for poset to 1 half or not. This would make this will make poset guarantee similar security as bitcoin. To do so, the natural question step would be can we have a less frequent update of randomness that can push the security threshold against private attack to poset half or not? So we find out that the answer is yes. So with less frequent update of source of randomness, the source of randomness required for computing the eval function of BDF for proposing the next block is updated once every seed for illustration. Consider this blockchain with resulting randomness from the computation of eval functions for each block being also depicted. Consider epoch of C consecutive blocks, then under the idea of less frequent update of the source of randomness, the randomness embedded in the genesis block is used as source randomness for computing the eval function for each block in epoch 1. For blocks in epochs 2, the randomness embedded in the last block of the epoch 1 is used as source randomness and so on. This changes the modest opportunity for how any node, any new node can join the system. So now assuming that all the VDS are of the same speed, if an honest load joins at the middle of the epoch, it would never be able to participate in the evolution of the system as its BDF will be always lagging behind the VDS for the existing nodes. So any new node has to wait until the end of the current epoch and then they can start participating in the evolution of the system. So now by controlling how frequently the source of randomness is updated, that is by tuning the value of C, one can control the amplification factor phi C of the growth rate of the adversarial tree. For instance, for C equals to 1, we go back to our original case of updating source of randomness in every block, which gives the highest amplification factor. For C equals to 2, the amplification factor is decreased. For C equals to 3, the amplification factor is decreased even further. We show that the amplification factor is a decreasing function on C. Eventually for C tending to infinity, we have amplification factor approach 1, which is also the case in bitcoin. So now the question is that with randomness being fixed for C epochs, is unpredictability even possible or not? The short answer is in post-site with its careful design, it still retains its unpredictability. Let's understand how. Consider this to be the state of the blockchain with RS0 being the randomness embedded in the last block of the epoch. Now, after receiving this last block, any node will start evaluating the eval function of VDF with RS0 being the source of randomness. The VDF guarantees that the unpredictability when this node will be able to become the winner of the lottery. Suppose that the node is able to win the lottery and propose a block with randomness RS1 embedded in it. Now this node will start evaluating the eval function of VDF with RS1 being the new source of randomness. So this new computation can be thought of as a continuation of the computation that has been done since the beginning of the epoch. Again, the randomness in VDF guarantees unpredictability when this node can win the next lottery. Incorporating all these design choices, we finally present the main theorem that guarantees security for posets while ensuring dynamic availability and unpredictability. So for some time t, consider all those on a stake that have been online in the system since at least time t minus bit theta c. Represent them by lambda f ct. We assume that this lambda f ct is upper bounded by lambda max, which is a valid assumption in the poop of stake system. Let lambda at be all adversarial stake online at time t. Let delta be the network delay. Then if this condition is satisfied, this big condition is satisfied, then we can show that the poor poset is secure against the private adversarial attacks. I'd like to point out that using proof techniques from everything is a waste paper, like the techniques like block tree partitioning and Nakamoto blocks would provide a security proof that shows that this security theorem holds true for all spectrum of attacks and not just private adversarial that we have discussed in the previous slide. So let us see how to prove this security theorem for all attacks. In order to prove the security of poset, a series of four system transformations are done in such a manner, so that if the system at the end of the fourth transformation is secure with high probability, then the original system that is poset is also secure with high probability. With the system at the fourth transformation, it is much easier to analyze the security using tools based on branching random box from everything is a waste paper. So the first system transformation is important for incorporating all possible adversarial attack and not just the private adversarial attack. To appreciate it, we start with the simple scenario of private adversarial attack. Consider this public canonical chain, but each of the blocks have been made by honest tools. Let us consider this on one is block H1 and see how private adversarial attack against this block works. Under private adversarial attack, the adversarial nodes would only make private adversarial chain from one of the ancestral blocks of H1 and make it public once it becomes longer than the canonical public chain. At this point, this adversarial chain would become the public canonical chain. This affects the liveness and the persistence of transaction in the block H1. Due to nothing at stake, the adversarial nodes can mine many more private adversarial chain. In order to show that the system remains secure, that its block H1 is persistent and life, it is clear that one has to evaluate the growth of the canonical chain and all possible adversarial or private adversarial chains and show that the canonical honest chain always grows at a faster rate than all private adversarial chains for all time. However, in reality, the blockchain is a mixture of blocks mined by adversarial and honest nodes. There is forking going on among honest blocks due to latency and some of the adversarial could be public. Some of the adversarial blocks might be private, so we need a clean way to evaluate this growth rate of the adversarial trees and honest blocks. This is where the first system transformation comes into the picture. For this transformation, we consider an hypothetical omnipresent viewer who is able to see all block mining, honest or adversarial, without any network latency with a global clock in hand. Assume this time axis of the global clock which starts at time 0. The genesis block is considered to be honest and it's put into this fictitious system dying 1 at the beginning. Suppose the next honest block H2 was mined after a time that is more than the network latency delta away from the previous honest block H1. So in this case, we append this block H2 to the fictitious honest chain in the system dying 1. Similarly, for this block H3, which has been mined more than network latency delta away from the block H2. On the other hand, if this honest block H, if an honest block is made less than network latency delta away from this previous honest block H3, then it is put in the same level as the previous honest block in this fictitious system dying 1. As for the adversarial blocks, all adversarial blocks that are reachable from the honest block H1 without going to another honest block is put as an adversarial tree rooted in the block H1. So similarly for this adversarial block on the left hand side, which is reachable from the honest block H2 without going to any other honest block is put as an adversarial tree rooted in the block H2 in this fictitious system dying 1. So now this view resembles the system view in the simple scenario of the private adversarial attack. So let us see what do we get from this system transformation. Consider this fictitious honest chain in the dying 1 system. Consider this honest block J and consider this to be the depth of the fictitious chain going through this fictitious chain going through this honest block J in dying T. Suppose these are the lengths of the all the adversarial trees rooted in the ancestral blocks of the block J at dying T. Then this block green block J is called Nakamoto block. If the depth of the honest fictitious chain is longer than the than all adversarial trees rooted in the previous honest blocks for all dying T, presence of Nakamoto block in the fictitious system indicates that the prefix of the block J in the original system denoted here this prefix denoted by the CJ will persist in the canonical chain for all dying T. Therefore, for any time T and for sufficiently long interval length S, we want to show that under some conditions, there exists a Nakamoto block within this interval with high probability. That would imply that there will be frequent occurrence of Nakamoto blocks, which would indicate the liveness in the original system. So using remaining system transformation, we want to show we show that the probability of non-existence of Nakamoto block in in a sufficiently long interval at any time T is negligible. So the second system transformation removes the mining leg. Let us understand what is this mining leg. Consider this fictitious honest chain at some time T. If a new node joins the system, it cannot participate in the evolution of the honest chain immediately, as we discussed before in the FORSET protocol. So it has to wait until the end of the current evoke epoch to be able to participate. That implies that the honest take that participates in mining remains constant within the epochs. And any analysis would have to take into consideration this timing random variable. This leads to the complexity in the analysis. So Dying II system removes this dependency. In Dying II system, the honest take can participate in the evolution of the honest chain if they had been active since at least certain sigma c times. We show that the probability that there exists no Nakamoto block within the interval of length f in Dying I system is closely approximated by that in system Dying II. For the third transformation, we go from a dynamic system to a static system. So again, consider this snapshot of the Dying II system. Observe that in Dying II system, honest take that can participate in evolution of the system can vary with time. Similarly, the adversarial state that can participate in the evolution of system can also vary with time. This time varying nature of the state makes the analysis complicated. However, having a constant stake over the system's clock would make the analysis much more simpler. As has been done in the original, everything is a waste paper. So we have a new fictitious system as 0 to do that. Given that we have this constraint on the relationship between the adversarial and honest take, we assume that the adversarial stake is at its maximum. We pick a certain positive number lambda h and evaluate a function alpha t. This alpha t would become the local clock for this fictitious system SS0 with respect to the local clock of the Dying II system. Now in SS0, we have constant adversarial stake from the perspective of the local clock of SS0. So this graph shows the local clock of SS0 with respect to the local clock of Dying II system. Now both the adversarial stake and the honest stake are constant. So we show that in this transformation, the probability of the non-existence of Nakamoto block within an interval of length s in Dying II system is less than that in the static system SS0. In this final transformation, we upgrade the adversary by giving it additional powers. Let us understand why we need to take that step. Consider this state of the system SS0 with its honest chain and adversarial trees rooted in blocks f0 and h1. Observe that the depth of these adversarial trees at any time are dependent on the location of the root block on the chain, especially due to the randomness grinding, which it can only do at the epoch ending. We can have easier analysis of the non-existence on Nakamoto block if the height of the adversarial trees are independent of the location of the root on its block. So in this new system SS1, we featured a more powerful adversarial model, but in an adversarial node minus a new block at the beginning of the tree, it gets a one-time gift of c minus one block. Fc is the epoch length. This also signifies the end of the epoch so the adversary can grind over the randomness tree. After that, the adversary operates as it operated before and there are no more gifts. Similarly for the other adversarial trees, we show that the non-existence on Nakamoto block in SS0 is bounded by that in SS1. Now in the static system SS1, we analyze the non-existence of the Nakamoto block in any sufficiently long interval of length. To do so, we employ the techniques from everything in the waste paper. First, we analyze the growth rate of the adversarial trees in SS1 using branching random walks. Then we show that if this particular condition is satisfied, then following events, following two events, happens for every block within the interval length with negligible probability. So the first event is that any nearby adversarial trees can catch up with the fictitious honest chain very soon. It happens with very negligible probability. The second event that any adversarial tree catches up with the fictitious honest chain far ahead in time also happens with negligible probability. This would imply that the event that there are no Nakamoto blocks in an interval of length S happens with negligible probability. Now the question is what is the right value of C, this right value of C, the epoch length to choose from. In one hand, we have the dependency of the security threshold on C. It shows that with increasing the value of C, the security threshold approaches the desired value of one house. On the other hand, the latency to confirm transactions is directly proportional to C. This creates a tension between the security threshold and latency. So depending on the application, if you are geared for security, you would tune the parameter value to be a bit higher. If your application is tuned for less latency, then you will tune, then you will have your parameter C to be a bit less. So this is how you choose the value of C. So to summarize our work, the process successfully guarantees proof-of-works dynamic availability and unpredictability while being provably secure under honest majority. So for future work, one direction we have been taking is to think about taking it is to upgrade POSAT to have the feature of dynamic state. So in our current model of POSAT, every node has a static state that remains same from the genesis. How in practice, adversaries can grind on keys of their accounts and transfer state to useful accounts. Having dynamic state would save God POSAT from such grinding attack. Another path forward is to see whether one can build a dynamically available proof-of-stake protocol that does not require any dependence on the error of time such as BDF. Finding an impossibility result or otherwise in this regard would be interesting. That's all for my talk. Awesome, perfect.


An anti-guerrilla raid in Vietnam. There is danger here, danger and discomfort, and sometimes death. There are also Americans here, not to fight but to observe. A soldier is trained to command, but there are times and places where all he can do is advise. Such a place is the Republic of Vietnam, where the American military advisor is expected to observe, talk conclusions and give counsel. He may also teach and be a useful friend. What he teaches is the soldier's art. He brings with him years of training in the armed forces of the United States, and because he has been specially selected for his work, a personal aptitude for diplomacy. He also brings courage. For those attempting to destroy this young Republic in Southeast Asia, are well aware of the role played by such advisors in frustrating the attempt at subversion. The American advisor in Vietnam has no immunity from terrorist bullets. Such are the conditions under which he works. This is the story of what he does. This is United States Army Captain William R. Johnston, a native of Michigan with a wife and two children in Chicago. He is seen here within a few days of his arrival in Vietnam. He will be official U.S. advisor to the 1st Battalion, 11th Regiment, 7th Infantry Division of the Army of Vietnam. In particular, he will work with Vietnamese Captain Trang Nhan Cong. His success or failure will depend in large part on the kind of personal relationships he is able to establish. The job will be a little easier because as part of our military assistance program, Captain Cong has already received training in infantry and artillery tactics in the United States. He knows more about the traditions and customs of Captain Johnston's people than the Captain knows of his. The success of any military advisor depends on his ability to grasp the historical background, the customs and conventions of the people he has sent to advise. Unless he develops for them a thorough and sympathetic knowledge, his technical military skills will prove useless. Before he can function efficiently, the advisor must gain a thorough knowledge with the men he will try to help make and do still better soldiers. When Captain Johnston joins his battalion, it is stationed at a sugar mill located in the Mekong Delta, a region notorious as a center of guerrilla terrorism. The mill is the chief source of sugar, rum and molasses for the whole Republic of Vietnam. The first battalion is here to provide security for the mill and to prevent Viet Cong, communist guerrillas, from extorting a tax trying to bring in sugarcane. It is the nature of war in Vietnam that the ordinary affairs of business and commerce must often be conducted in an atmosphere of an armed camp. Advisor Johnston begins by learning. Both from Captain Cong and Sergeant Dach, a former school teacher who serves as interpreter. One of the first things Johnston learns is the difficulty of identifying the enemy. In an area largely controlled by the Viet Cong, it is estimated that fully one-third of the mill's employees are themselves part-time guerrillas operating at night to terrorize the surrounding countryside. Some things an advisor can do immediately. An artillery emplacement is an artillery emplacement. A well-trained officer can offer a number of suggestions for increasing the effectiveness of the battalion's howitzers. He can also suggest that troops in garrison need not settle for shelters improvised from ponchos when their own labor could supply semi-permanent barracks. But for the larger problems, those which typify the undeclared war being waged against the whole of South Vietnam, there are no quick solutions. How, for instance, do you defend endless miles of exposed road between the sugar mill and its major market, the capital city of Saigon? Any morning, word may arrive that in the darkness of night, guerrilla bands have sabotaged the road, making it impassable. Officers and advisor can investigate, summon troops, but their chances of accomplishing much are slight. With miles of jungle into which they can vanish at will, the guerrillas responsible for the sabotage are as elusive as field mice. In the rice paddies and bamboo thickets of the Mekong, odds favor the guerrilla. Aware that attempts to intercept his retreat into the sheltering jungle will be almost impossible. The guerrilla adopts as his motto the adage that he who fights and runs away lives to fight another day. The guerrillas vanish, leaving only civilians protesting ignorance of the whole affair. With the guerrillas driven off or underground, it remains to repair the damage, a job which falls to civilians from the area recruited by the government's district chief. Here is a poignant example of the irony and the tragedy of Vietnam. For many of these same villagers have undoubtedly spent the long night under the menacing guns of guerrillas digging the same holes they must now refill. Destroy its transportation and you threaten the life of a nation. A modern nation like the ancient Roman Empire cannot long survive if her people and her commerce are denied roads and highways on which to travel. Much of the struggle in Vietnam has become a ceaseless effort by guerrillas to close the highways of the government to keep them open. Like others, Johnston is well aware that there will be no real security until the guerrilla can be denied free movement through the jungle. Nor is there any reason why government troops should not take a leaf from the guerrillas' book, stationing themselves in the jungle for a nighttime ambush. An obvious need for regular, aggressive, night patrols throughout the area. But such tactics run counter to those taught Vietnamese troops for more than a century, based on the venerable military maxim attack by day, by night, defend. At considerable personal risk, Captain Johnston demonstrates the effectiveness of night patrols by accompanying them himself. Eventually they become part of the battalion's standard procedure. This too has become standard procedure. American helicopters have brought mobility to Vietnamese troops in their efforts to pin down the forces before they can achieve their customary disappearing act. The helicopters are flown by U.S. Army pilots. Part of the U.S. advisor's job is to coordinate the helicopter elements with the Vietnamese troops whom they carry and will do the fighting. From the air, hidden waystations along the guerrilla supply route are found and destroyed. A communist propaganda booth is discovered and destroyed by Johnston's battalion and a local village such mobility can be effective. The test is the death or capture of hard-core guerrillas. In any engagement, many of the guerrillas will prove to be half-trained propaganda indoctrinated villagers or farmers. All prizes are the professionals who do the training and the propagandizing. Men like these, long sought by the government, has known professional terrorists. It is also an American advisor's responsibility to help get armor support for his unit. These armored personnel carriers have been brought in at the request of Captain Johnston to assist the first battalion in an anti-guerrilla sweep of its area of the Mekong Delta. In such terrain, the effort to uncover even a single guerrilla is so great that one observer has compared it to a thousand-dollar bill chasing ten cents around the rice paddy. The situation is inevitable, however, until the initiative is seized once and for all from the Viet Cong. Until then, every resource of equipment, tactics, and strategy must be brought to bear on the problem. It is an advisor's job to make his counterpart aware of what is available, encourage him to use his artillery, his engineers, his communications, his ordinance, his medical facilities, and to coordinate his efforts with other services. Since the battalion to which advisor Johnston was assigned has the primary mission of defending a guerrilla-infested area, the captain finds himself helping to train men who have already known months, and in some cases years, of combat. Because no one can predict when a training exercise might suddenly become the real thing, classes are conducted with loaded weapons. No matter what the difficult is, no matter how blooded by combat they may be, troops must be continuously retrained if they are to win a victory in war. With training comes success, without it, disaster. The Vietnamese is potentially an excellent soldier. He has intelligence, agility, and courage. Properly trained and motivated he can become one of the best fighting men in Asia. To encourage adequate training in the military arts and science is perhaps the most important job of the American military advisor in Vietnam or anywhere else. He teaches by demonstration as well as by lecture. Here he lays wire for a demonstration of the Claymore anti-personnel mine. While his interpreter explains the function of the mine from notes prepared for him by Captain Johnston. While teaching technique to the men Johnston is also communicating by example a subtle message to their commanders. There is nothing wrong about getting your own hands dirty in a job. The anti-personnel mine has great potential for the war in Vietnam. Used properly it can have devastating effect on the night traveling bands of guerrillas. It is an advisor's job to gut such equipment into use by increasing the number of Vietnamese officers and troops who know how to use it. With two thirds of his Vietnamese tour behind him, military advisor Bill Johnston takes over the units of the regiment in the fortification of a native village. It is the battalion's responsibility to provide from their own supply stores a large portion of the food, medicine and household goods necessary to set up whole families of Vietnamese whose men folk belong to the self-defense corps which will defend the village. It is on the Buddhist calendar the year of the tiger. Somehow this seems appropriate. With the captain's own tour it is the first Lieutenant Joe Clement of Atlanta, Georgia who may ultimately be his replacement. Lieutenant Clement has four months to learn his way around. He'll need them. So will master sergeant Jones of Baltimore the battalion's first enlisted advisor. The object of this program is to draw together residents of tiny villages scattered throughout the area and relocate them in larger communities which can be fortified to resist roving bands of guerrillas. The troops are here mainly to guard workers during the construction. Protection must also be furnished for laborers on a nearby road project. Shortest route between the village and the capital at Saigon the road was rendered useless by Viet Cong saboteurs more than four years ago. It must now be put back into use and somehow kept that way. Reconstruction is accomplished by Vietnamese Army engineers. Assistance is also rendered by local civilians recruited by the district chief. Captain Johnston speaking for the infantry consults with other U.S. advisors attached to the engineer units. In Vietnam the main arteries of travel and commerce are not concrete but water. Vietnam's many rivers and networks of canals have been for centuries the key to the nation's economy. These two must be kept open free from guerrilla harassment. While less permanent damage can be inflicted on such a waterway everyone travels in peril of sudden ambush from the surrounding jungle. It should be said that part of an advisor's job is to acquaint himself with the ordinary citizens of the country to which he is assigned. On occasion advisors may assist other agencies in the distribution of books pamphlets or school supplies. But their main concern is directly military. On this occasion for example Johnston has recommended the movement of guerrillas from battalion headquarters down river to a key site in the delta canal system. Their self defense corps volunteers can protect farmers trying to get their produce to market. Putting an end to systematic Viet Cong extortion reported from that area. On the advisor's recommendation troops are sent ashore to dig in and secure the area before barges are landed. Failure to take such precautions in the past has resulted in serious and unnecessary losses. For as Captain Johnston points out to the regimental commander the Viet Cong will attack by day if the stakes are high enough and there are ample clues to the presence of guerrillas in the area. With the area reasonably secure the first craft an American LCM can be signaled to come in. Following plans drawn up jointly by Captain Johnston and Captain Cong the battalion begins construction of fortifications for a native village their purpose in making the trip. A triangular wall is built with mud dry it will be almost as hard as concrete and a good deal easier to come by. So far as possible building materials are collected locally. Captain Cong personally supervises most phases of the construction something he might not have done a few months earlier. Johnston's presence has had its effect the ground can be seen smoke from fire started to clear the brush from the surrounding area depriving guerrillas of concealment near the outpost. At each angle formed by the mud triangle a block house is constructed a wide moat is dug around the entire post reminiscent of the middle ages but highly effective against guerrillas inevitably there is a casualty a self-defense corpsman dropped by a single bullet from an unseen sniper. Johnston radios a request for helicopter evacuation hoping to get the wounded man to a hospital in time to save his life. Maximum care for wounded in the field is something any American advisor can be expected to stress and is in sharp contrast to Viet Cong treatment of their own wounded. The lesson is not lost on Vietnamese troops fortifications nearly completed the battalion starts to move a bulldozer across the canal on the other side of which it intends to reach tower and now mud recently so useful becomes a king size nuisance with an unknown number of Viet Cong in the area waiting for just such an opportunity this delay could prove a serious matter. Either the bulldozer will be pulled out before their plight is discovered or the battalion can expect to lose both its equipment and a good many lives. The mission is completed. The fortifications have been built fence corps men their families and villagers move in bringing firewood for cooking and drinkable water a scene of domestic tranquility against a backdrop of anticipated violence the village fortifications built and men in place to defend it the battalion heads for home it arrives with a few unfriendly companions Viet Cong guerrillas encountered on the way home the battalion has done its job well returning home in good order with a minimum of casualties good news but for captain Johnston the real news is that he too is going home his year is up and there are those two kids and wife back in Chicago yet in parting there was also a regret Johnston and the men of the first battalion have shared much together have suffered much together in ways that only they can fully understand he leaves behind many good friends he leaves behind someone else as well his successor lieutenant clement who for the next year will be the battalion's new American advisor what Johnston learned Clement now knows within the guidelines laid down by us policy the lieutenant must now seek to further in his own way what was begun by captain Johnston and his predecessor there will be problems and he knows it but the new advisor has more to on than did captain Johnston as a year or so from now the American who comes after lieutenant Clement will have more than he so it will be until peace finally comes to this beleaguered republic a peace for which the arming advisor in Vietnam will be in no small part responsible


But I think we can get started anyway. So with that further ado, let's start the recording and get going. The recording has started. So keep going. All right. Thank you. Hello, everyone. Welcome to the TSC call. First and foremost, please be aware of the antitrust policy notice. For those who were actually connected online, you can see it being displayed on the shared screen right now. You should all be familiar with it. There is also a code of conduct that you should be familiar with. There's nothing really extraordinary about it. It's just basically asking everybody to participate in a decent way. So be familiar with this. Regarding the announcement, I had one item which is minor announcement, but so a while ago, we decided to adopt this mechanism to keep track of the TSC decisions because historically, they've been kind of disseminated all over a week in meeting records of one kind or another. The problem is we started using the system which I think everybody has agreed is really a big improvement. Promise there is no history called data in it. To the point, there were questions raised about, so what does it take to be able to publish a first major release, for instance, and I remembered we made a decision on this, but actually finding it wasn't so easy. So basically, the announcement I wanted to make is, I started going back into the old decisions we've made and put them into this. So it's just a very simple record that basically captures the decision that was made and as a link to the actual decision in the previous, the older record for the decision. So as time permits, I will keep doing this as we move forward because I think it's a bit of a pain to do, but it's useful to have a consolidated list of all the decisions so that people don't have to look all over the place for this. And if anybody wants to chip in, please let me know. I'm happy to share the load with anyone else who wants to do this. All right, so without further ado, let's move on unless there's any question, but I wouldn't expect so.  Some of which were kind of delinquent from last week, some where I'd been submitted just before the call and people didn't have a chance to review them. So I put them all back. I have seen a lot of notifications and just like 15 minutes ago, so I went through all the reports and I saw that for the most part they've been reviewed by most of us. So I have pretty, you know, I'm pretty confident that people know what they contain. I'm going to go through them very quickly. There is nothing special about grid that we need to talk about. For the BESU report, there are two issues that were brought up. There is one with regard to the rocket chat access in read on e-mode. And I think that's worth a bit of discussion. And the other one is to do with the active status, the requirements, that's a bigger discussion that we can discuss later. Is there anything else that people won't talk about BESU or any questions? I think one thing we need to work on is we've said that for the working groups that they're going to deliver a product, you know, some tangible thing they need to have a task force. Are we grandfathering? Yeah, but that's not part of BESU, right? Okay. It was regarding to the smart contracts working group. I got you covered there. It's coming. All right. Sorry. No, so we got to BESU. Can we talk a little bit about this redone access? So the BESU team is reporting that, you know, they feel like there's a barrier to using rocket chat because it requires having a Linux foundation ID. And if you're just passing by and you just want to access some information, you don't necessarily want to participate. And is there a way to get grant redone the access to rocket chat without identification? That's basically the question. And please. There is. Daniel, if I get that wrong, please jump in. So there is. And it's kind of a, this is a side effect of the behavior that they're seeing is actually a side effect of enabling anonymous access, particularly to search engines. So this is part of a discussion that I would like to have in the new year about what is the future of chat for hyperledger? So I would ask, you know, that, you know, we plan on rocket chat issues. Okay. So maybe can you take the action to open and issue them with regard to this redone the access to rocket chat? Does that make sense? Sure. That way we look at it whenever you feel like it's good time, but I just don't want to lose it. Yeah, no problem. So, Ryan, are you suggesting that there should be an alternative approach or reconfiguration or what are you thinking about there? I think that we should reconsider our chat platform. I've certainly got tons of feedback about that. I don't know what that would be. We ended up here for reasons of cost. Yeah. That has to change. Because we couldn't archive, right? Because if we wanted to archive everything, we would have to pay a facility in dollars. Yeah. Right. Slack has the same issue, right? Sorry? Slack has the same issue needing to create an account to get in and start using it if you were to. Right. That's right. So Slack has a different set of similar problems. Mattermost has been suggested. There have been a lot of suggestions about other chat platforms that we could move to. They'd be curious to hear from the basic team their experience with Gitter. So Gitter is driven off of GitHub user IDs. From my experience, it logs all the way back, although that might just be a restriction for open source only, which actually for what's going on with Hyperledger would qualify. The great thing is we can give them a link and they can go straight into the chat room where they can see what the discussions are. And with Rocket Chat, when we give them a similar link, they just get never ending triple dots loading. And that's kind of a bad, that's a feel bad moment for sure. Okay. Well, we don't have to discuss it here. I just wanted to, I was really just trying to get Rai to sort of clarify what he's after. It sounds like Rai, you're suggesting we should look at another platform as you just confirmed. It used to be that you would actually be able to see the channel and there would be a fine in button at the bottom of the window. So there may be an outstanding or an open issue in Rocket Chat to fix that. Yeah. So I don't wanna dig into this. The way the behavior today is because of enabling search engines to be able to index Rocket Chat. So if we turn off the login splash, which is totally a setting we can do, then it's apparently unindexable for some reason. I don't remember. It's been a couple of years. We could either improve the Rocket Chat platform, move to another platform, but I do know that LFIT no longer supports bringing on new projects with Rocket Chat. And I think our experience has been okay, but not awesome. It's not awesome. Okay, so Rai, Rai, could you just have another look at this particular issue? Is there a way we can open the door so that, you know, the situation that I was just describing would be addressed? And then we can table off the trigger. No, then we can table off the bigger question of whether we should switch to a different platform altogether. I don't want to mix the two issues. I understand that, of course, if we switch platform, then this issue goes away. But, you know, it may take a while before we switch. And if there is an easy fix right now to give access, redone the access to anonymous users, I think that would be worth looking into. Okay, so let's keep on moving then. Smart contracts working group. So as Mark was eager to point out, in their report, they don't bring up any specific issues, but they do highlight that they are planning on producing a bunch of reports and byproducts. And so the question is, you know, given the decisions we've made with regard to task forces and the fact that working groups are not expected slash not allowed to produce anything other than through task force, do we have to tell this model of contracts working group that if they are to produce anything, they need to create a task force, or task force if the case might be. Yes, hello, this is Sofia Perzi from the Smart Contracts Working Group, I'm the chair. So I'm here to know everything that we should regarding the task force, if there's something you want to tell us and move the world to the people there. I think we also have the same type of issue with the DCI working group. Is Dan on? Yeah. Yeah, so we're in the middle of producing the survey that was originally chartered. So my preference would be, we've already chartered these things or at least in that case, the DCI one within the last few months. So just issuing more paperwork seems arbitrary and unnecessary, but going forward any new work product that's gonna have some sort of hyper ledger logo on it or affiliation in that you follow the new process that we've agreed to. I've y'all checked out their space on the wiki because they have a space where they've got all their work products all documented and drafting live on the wiki. Right, any opinions that don't hear much? I, yeah, other than Dan, so he's just, I believe to grandfather at least this working group, which is consistent with his position, you may remember he voted against this requirement that working groups can only produce deliverable through tasks, so I understand where it's coming from. But Mark, in your comment, you also suggested maybe we should grandfather this. It was more, you know, just we changed the rules and we didn't account for things that were already in flight. So how do we wanna handle things that are already in flight? I also have another thought that maybe it's a bit tangential, but as far as who's eligible to vote in TSC elections, if we add something when we get the specifications for what a task force should do, if we added a list of contributors there, then we would have a list of people who have contributed in the working groups. But that sort of rules out working groups that don't actually deliver anything. So, I mean, it's a different thing, yeah. Let's not turn that on now. You should see my world. I'm happy to leave that working group alone, let them do what they were doing. Anybody objecting to this? I think grandfathering is kind of the norm, right? Unless we have a really strong reason to say no, they need to stop the way they are doing their thing. Okay, I didn't hear anything. I'm in favor of allowing them to continue on the work items that are already planned without a task force.  Sure, I make a motion that we allow current working groups that have things in flight to continue without going through the process of forming a task force. I second that. I serve that. Right? Anybody in agreement with this, say hi. Hi. Hi. Hi. Anybody opposing it? Anybody abstaining? Okay, so it's unanimously approved. Thank you. All right, so let's keep on moving then with the reports. Ursa, there's no major issues on this report either that I think is worth highlighting, but they do point out that they would welcome feedback from the project maintainers as to what would make Ursa more attractive or what would make it, what would make the maintainers use Ursa. We don't have to take it on now. This is a call for feedback input and the door is open. Please reach out to the Ursa team and let them know. And the final report we have today, oh, well, is there any questions about Ursa before I move on? Okay, hearing none, let's move on. The last report is Explorer. And so there is no major issues with Explorer either. They've issued the first release candidate and for one zero and they are trying to figure out their way to get to the one zero, which we'll talk about later. And they do highlight that they are struggling a bit like many other projects on the diversity aspect. Any questions or comments on this Explorer report? Good morning, this is Nick Explorer. Yes, indeed, we have outages of contributors and I would like to ask if you have any suggestion how to recruit, honestly, I'm being very sometimes direct to developers that are trying to use Explorer and trying to hiring them, recruit, but people just are coming, sometimes they're wishing to contribute and then they leave. So what would be your suggestion in terms of like getting more contributors? Ways to, not sure, maybe some projects can share their contributors or something else. I don't know even what would do. I understand. So typically, yeah, so there's actually some really good blog post articles, whatever you want to call them off of the Red Hat open source pages that speak exactly to that. How to grow your community, how to engage developers and so forth. And you kind of touched on probably the most important one is your users are probably your greatest source of potential contributions that basically you have to nurture it. I think we all have a little bit of work to do in that regard, but basically, when people come and they start using it, encourage them to contribute or ask them if they have any specific ideas about the features and so forth, that's the best way to get them engaged. But I would encourage you to take a look at the Red Hat open source pages or I think a link to community or something like that. And then we just send it. Yeah, thank you. materials. Thank you. What is good about that? I'm seeing that people are using, companies are using it in production. And with some releases that we minified the configuration, I see less complaints on rocket shop, which is a very good feedback and going forward, I think it's going to be a very good experience and to get more feedback from the users. Other than that, as you mentioned, I hope the moving point of getting into the major release one and moving forward to graduate from the incubation, the explorer, so yeah, I would like to talk about that. Thank you. Yeah, so I put that on the agenda as a separate item. So we'll get to that later. Thank you. And quite frankly, just to add to what Chris was saying, this is something obviously a lot of projects are struggling with. I'm afraid there is no magic bullet. And we have been through this over the last four years of hyperledger many times where people are trying to share pain and stories and about even when they're trying really hard and doing everything they can to bring people in, it doesn't always work. So Composer comes to mind, for instance. So there are other projects that have been struggling with this. Okay, well, so. We'll be interested. There's a bigger problem. Right. You don't have to get to it, but maybe it's tied to the rest of them. There's a bigger problem, actually, right? I mean, I actually think that people actually, anyway, I won't get too much into it, but I think people don't really understand sometimes what hyperledger is. And I think that sometimes it's propagated by hyperledger. I think people actually think that hyperledger build products. I think it's a problem. We have a lot of users. Users don't typically contribute, but people think that these are products. And I think that that's an issue. I think on the hyperledger Explorer, what my issue, and I did go back and look at it, so it did look pretty good. My issue on it was that it had been dormant for a while. But it does look like over the past year that contributions did go back up. I think that's the sort of concern on why people were looking at making sure that there's people, more maintainers or whatever, that if something does go into, say, an active status, that it's not just going to go dormant at some point. But maybe when we get to the future conversation, well, maybe there's a stuff that says, well, if that does happen, maybe a project does become dormant or go back in status. I think that's the bigger concern. That was my one comment on yours. So I thought that that was that. I will just say that I didn't update my comment, but I do think that it did look like the contributions had been very steady over the past year. So apologize for my comment on that. All right, let's move on, because I don't want to spend too much time on the reports. I'd like to get to some of the topics of discussions today. The first one is the management of quarterly reports, the TSE, which we just went through. So admittedly it took us, even though I tried to speed it up, it still took us 25 minutes. And so Rai kind of raised this issue a bit obscurely and it created a bit of confusion, but I had a chance to chat with him and basically he's saying, maybe we shouldn't discuss any of this on the calls and we should do it all entirely offline. I don't know how people feel about that. It sounds a bit extreme to me, but I just, you know, that's what this is about. I think we're getting much better at being efficient and going through reports and it gives us a chance to have discussions on things and see broader issues. Yeah, we want to give people who are reporting the chance to bring up their issues to the TSE if they want. I also feel that this is a primary function is to have this kind of oversight and figure out when there are issues and address them and whatnot. And this is an important part of this. And I'm afraid historically we have not been specifically good with working offline and so even though we should keep encouraging this for, we can't just completely rely on it. Chris? So to your earlier point where basically you went through and you sussed out what you thought were the issues, maybe there just should be a section we add at the end for any issues you want to bring before the TSE and that triggers a review on the call. We have that in the template. It's not at the end, it's close to the top but it's in the report template. This is how I came up with those things that I highlighted what's in those reports. So that's done. Okay, so I don't hear anybody saying we should change that we were doing it right now. Is that correct? That's correct. I think it's valuable and when we don't have eight of them on the schedule which we're not supposed to have eight at one time, then it actually only takes a short amount of time. Yes, I agree with that. And then immediately I could have postponed a couple of them to make it lighter. So all right, do we need to make a decision on this?  So the horse is truly dead and beaten. So let's move on, please. Okay, that's good. You can mark it as withdrawn if you want. Thank you. All right, so following up on the Bezu request to move to active status, there's of course the big discussion that keeps on going as to the diversity aspect but I think Daniel actually raised the point which I think is fair is that they're saying, okay, is there anything else we need to worry about? They just don't want to have this feeling of having a moving goal post where every time they work hard on reaching one of the, meeting one of the criteria we have highlighted, we'd say, oh, but there's also this and there is also that. So can we, I wanted to ask the TSC specifically if there is anything else? Because I mean, as far as I'm concerned, that's the only one I've heard really being expressed and discussed. I don't know if there's any others. I would just say like use of the hyperledger community tools is the other one, right? And I think that comes with time. I don't think that comes with like, I've done it, check. I think, you know, as we've seen the problem with rocket chat not working well for Bezu, are there other things that won't work well for Bezu with the hyperledger tools? And I think that's just a timing issue, right? Like you've now switched over all of the tools to using the hyperledger community tools. What are gonna be the issues that you uncover? And, you know, that's the big one. I think, you know, for me, when I used to explain what it meant to be active, it was that the community has formed and gelled and is using, you know, hyperledger processes and really kind of understands that, you know, and can do releases and using the hyperledger tools. So to me, I think that's the other one that would be outstanding. All right, thank you. Anything else, anyone else? Okay, so at least we've got that clear, clarified, Dano, is that okay? Yeah, I think we're there on the tools, but it's not worth bringing up for a vote until we can satisfy people with the diversity concern. Yeah, no, but we don't need to vote on every one of them individually. That's fine. Exactly. Tracy, do you have a list of tools in mind that you feel they're not meeting that would make you vote against it? It was required just so they know, I mean, they need a clear target, right? It's not that they're not meeting, right? They've switched over to Jarrah. They're using Confluence. You know, they're starting to use Rocket Chat, the mailing list, those sorts of things, right? These are the tools that I'm talking about, but I just think that there's going to be potential issues as they actually do releases, like with Jarrah, that they're not going to be aware of the fact that this is how this is functioning on the hyperledger side, and they're going to have issues that they need to get resolved. And so to me, that just comes with using the tools that exist in hyperledger as they're going through and doing releases and having conversations with the larger community. So it's not that they're not meeting them. Check, I've done this. It's that, you know, I think it's using them in a longer period of time to find out all of those sorts of concerns and issues that they're going to have with them. Okay. Does that work? Mark. Yeah, I'm just trying to make sure they have, you know, a clear list of things, so. I understand. I think that's a good point. All right, so I don't hear anything. But what do people think that active status buys them? Okay, so that's that's. I don't really want to have this conversation with her. No, no, I'm supposed to. But what do you think it buys them? Yes. So there's the big question of active status. What does it mean? And the fact that, you know, it seems like the one item that everybody stumbles over upon is this diversity issue. The diversity criteria. And I assume you guys have had a chance to look, to read the Hart's book on the activity status versus incubation that he posted yesterday. And the, which is, which raises a very interesting point, right? And it talks about the diversity criteria, which is actually fairly well defined in the, in the exit criteria for incubation. But, you know, it still leaves room for interpretation. It's not completely objective. And so there is one part which is, which is like, you know, you have to have at least three maintainers from different organizations. So the Bezu team is saying we are getting there. And I trust that's true. And then there's the question of, well, which is harder to assess is, you know, whether the project is dependent on the single entity or not. Or another way to put it is whether it would survive if the, you know, any entity involved in the project were to walk away, which we understand they have no intention to do, but still that's the idea. And so I think Hart raises an interesting question and which touches upon what Gary just brought up is, okay, first of all, what is active status about? What does people expect to get from it? I think there's a bit of like a bragging right that people seem to be eager to get. And beyond that, you know, the idea was very much along with what Dan said in his message today is, you know, from a TSE point of view, we all agreed that Hyperledger was about open governance and we wanted projects to be not under the control of any single entity. And we wanted to work hard on encouraging projects to grow a community, which was as diverse as possible. And so we felt the active status was a good way to have this kind of carrot that would make people go for this and work hard towards it. As far as I'm concerned, this is what it's about. I understand it's hard to reach and it creates trouble. Now, you know, I'm not the judge here. I don't know what people think. Hard suggests maybe we should just get rid of it all together. So Gary, what do you have to say? I know you've missed a couple of calls. You wanted to talk about this. Is there more you want to talk about there? I mean, I think Hart covered a lot of the stuff that's in there. I guess, you know, at the end of the day, I think I'm just trying to figure out why people, you know, and I remember even when we did this way back when, right? And I kind of look at it when we were like, you know, pushing forward and pushing for like 1-0 stuff in the early days of hyper lecture, right? And it's a much broader discussion, right? But there's back to my other comment. I'm not, I guess I'm not sure what people really think it buys them or means or, you know, should we have tied this to like a release? Like I guess, I mean, you can give numerous examples of projects that were big projects, you know, outside of the organization that the ASF is the best one to look at, right? It's the biggest one out there. There are projects that were being used that weren't in Apache, have a user base, right? They come in to ASF, they come in as an incubator and some, you know, spend a year in an incubator, right? Because they had to go through a whole bunch of stuff that didn't do it. You know, I mean that people weren't actually using the code. Kafka is a great example of it, right? Which was primarily sponsored by LinkedIn. So I guess that's where I, you know, I don't know, maybe we've made this mistake of like tying things together, right? I think if people want to use, you know, maybe if you're an outsider, right? When you're an outsider and you come and look at hyperledger and you say something's inactive, I guess you want to have the concerns of that this thing's not going away, right? That if I start using the code, that it's not going away. So, you know, to me maybe we, and people are, one, that the code is governed correctly, right? Meaning licensing and all that stuff, right? Because that's put in there.  That are why people come to an organization. But I think the most important one is people would want to know, shouldn't stop them from using it, but they would want to know that the code is not going away. I think associating active status with the quality of code is wrong. Yeah, so we've tried to separate those two things and that's why we, but we have tied them in a way with the major release and maybe that's something we could decide to change. We could decide, you know, in light of what we are seeing also in the Explorer case, it's like, well, the code is mentioned here enough and you know, maybe they should be allowed to have a one zero release without being an active status. Let me ask the Bezu team. What's your motivation? I mean, this is an obvious, you know, question maybe, but why do you seem to want to, so eager to get there sooner rather than later? Part of it is that it's an indication of maturity in the community. And it's something that would distinguish Bezu from a project like Composer that was being aggressively abandoned and they're looking for people to hand it off to and no one stepped up. I think the big concern is there's no gradation between incubation and active.  You're either on the wall or you're not. And another problem is it's a one and done thing. Once you're done with it, you never have, you know, in theory the TSC could revoke your active status, it's never been done. But there's no gradation between our first day of the door and active status. If there was like a bronze, silver, gold type thing or like bronzes, you're on the hyperledger infrastructure, silvery as you're governing and gold as you have the community. I think that would remove a lot of the anxiety a lot of these projects have about getting to active level. All right, thank you. I also think just to, can y'all hear me? Just one thing is it's not necessarily a motivation. Like we thought we met the requirements. So it wasn't necessarily, you know, because we need the requirements, why wouldn't we apply if that makes sense? So just like looking at it that way, that's kind of our priority and we wanted to make sure that we wanted to, you know, if we, we meet them, why wouldn't we? It's kind of, I don't know if it matters what the motivation is as much. And that was kind of our window, our window of thought. All right, thank you. Anyone else? So what would happen to fabric if IBM decided to leave hyperledger? Do you see fabric being able to go on and continue with the developers it has independent of IBM? You're asking me? Well, I'll tell you what would it, well, there's a kind of a forcing function that it would probably have to happen at least for a short period of time, right? There's enough, so this is reversing it right from the beginning, but there's enough people out there who have built offerings around it. Big players who are taking money that they would likely have to, maybe we should, actually that's a good idea, Mark. Maybe I should just stop writing code and see what the Oracle and Microsoft and everybody else will start doing when there's no one to fix their bugs. But I think that's the interesting thing in there, but you are correct, right? I'm not opposed to Betsy, by the way, not, I don't actually have a problem that it's primarily maintained by other people in there, right? Tracy's points were the more important ones in the process and other stuff. No, my point was just, you know, we're trying to make sure that the project can continue if a particular company pulls out. And so I'm just looking at it from the different angle, what would happen to fabric if IBM pulled out or something, decided they're not gonna continue anymore. Yeah, I mean, there's the question of maintenance of the maintainer's diversity as well.  For me, sorry. I think these are good questions. We don't have an answer to, honestly. For me, some of this is setting behaviors that you hope continue on that, all right. Now people understand this isn't just my company's project, I've put it into this community setting in order to continue to mature it. It has to follow these community rules. And hopefully that continues on, but maybe one of those bigger contributors does go away. But hopefully the remainder of the community and the user community that's grown around it continues to fill in in the wake of that departure. I wouldn't be interested in trying to do like a continuous evaluation of whether something is in an active status. I think once you get there and you've established those behaviors, we're hoping you're just gonna continue those. It's kind of like passing a driver's license test. Once you have it, typically you keep it until you're forever. Bad example, they should be testing periodically. But they are not. I mean, it depends which country, but in France, they don't even expire. So you have them for life literally. So anyway, I don't want to spend all their time there because we're a couple of other points I wanted to touch on. But I think we, you know, what I take from this is there are a couple of specific issues we could consider in dependency. There is, you know, the hot question is like, the hot question is, should we just get rid of this for go the whole active status entirely and address this in some different ways? There is the question of whether the first major release should remain tied to this active status or not. And then there's another one which came up, we didn't really talk about it today, but it came up in the discussion that some of us had, including with Dano on the Wiki, which is, is there a way to put some kind of metric or formula to measure what the diversity, you know, what the diversity criteria amounts to?  On the other hand, it's more objective. And the other way is like, it feels very subjective and, you know, they feel like it depends on the TSEs mood, which is not very good either. So, I, is there, did, so I have, I raised like three different issues that I would be happy to capture independently and we can address those. Is there anything else? Does that sound good to you? Okay, hearing none, I will take this as a yes. And so I will actually capture those and we can actually hammer those offline on the wiki. Thanks, Hart, for starting the discussion on the whole, you know, question of whether we should even bother with this still or not. So, let's move on with the agenda. We have a related question. In this case, we have a similar request now from the Hyperledger Explorer project. They actually admitted themselves in their report that they are, the diversity criteria is a challenge for them. I don't know if there is much more that needs to be said at this point, but there is also these problems, even maybe more specific to this project is the tying of the major release with the active status is kind of burning issue for them because they would like to issue a first major release and yet they don't qualify as a four active status. So, when we initially put in the criteria for becoming active before you could have your first major release, it was really about whether or not Hyperledger would expend resources to market around that first major release. But I can appreciate that project that wants to suggest that, hey, we're kind of mature and again, with Explorer, as Gary pointed out, there was a period where it was fairly dormant. It's been obviously kicked up a notch and is fairly active now, but I think there may be a problem of first impressions and people don't realize that and maybe getting to a 1.0 release but without all the hullabaloo might be a good way for them to signal that they're still around. I don't know, but I mean, essentially, I just wanted to highlight the fact that this was really about whether or not Hyperledger would expend resources to market by getting press and analysts coverage and so forth. But maybe we distinguish between, when we talk about a first major release, which would require an active project. I see. So you're saying maybe we could have a first major release with that all the fell far. Without the hullabaloo, right? Yeah. Yeah. I guess you know it all comes down to, I guess what people want to have is external vision, right? There's plenty, right? There are a lot of things that we want to do, you know, there's plenty, right? There are lots of projects that people even make products from, right? That aren't at like 1.0, right? I mean, the biggest one, again, I'll just keep going to it. The biggest one of the biggest ones out there, right? Was Casco, there's a few other ones, right? People out there who are running like early versions. But I like Chris's concept, right? I think there's, yeah, what do you get, you know, on time? Yeah, I think if people want to make a statement about where they think the maturity of their release stuff is, right? And then want to follow the kinds of guidelines, right? Of typical releases and maybe we should separate the two. Oh, we also did the scans, too, right, Chris? There was also the, you get security, you get the security paid for and testing and all that stuff. And you find memories, right? We also made an exception. Was it for Iroha where they had a first release with that, first major release without being in active status because we said, well, okay, fine. No, we were in active status. You said so. I don't think, yeah, this is Aleš from Iroha. I don't think this is true. We were in active status in, we are remaining in active status. And since I'm talking about this topic now, I would also like to say that I see the difference. And I think it would be a little bit funny to have a project at 1.0 being in incubation. That might send a very strange message to the people looking at the project and being confused, what does it mean? So I think we should be following the life cycle that is defined, but maybe redefine the criteria within the life cycle, if that is needed. I don't know. All right, thank you for that. And I apologize for the mis recollection. I don't know why I have this idea that we had some exception at one point, but I can't remember what it was exactly. One just happened like two weeks ago, right? Someone went 1.0 without. Well, that's an accident because they didn't know and they just did it with a telegust. Oh, okay. That's not really, it's not the same as having the TSC say, fine, you can do that. All right, so maybe Nick, since you're on still, can you tell us a little bit more what's behind the request? What do you, is it really the motivation for moving to active status? Is it really driven by this, I mean, the desire to release Explorer 1.0? Yes, as Chris mentioned that the 1.0 may have a trigger on contributors. And I'm very actively on rocket shot and people are asking when the major release is going to be in and I'm seeing a lot of people are using in production, but some of them gave me the feedback that they are using and their financial institution, banking, government, different types, but again, it's very hard to get the real company names. They don't want, they don't want because of the known Explorer issue. And I think that will trigger more contributors. And I want to mention that the project since beginning 2016, well, maybe at some point of time, it was not in a dormant, but still actively contributors like from DTC, Fujitsu, Alturas, Technalia and actively we are responding to people and we are making contributions. So a good point and statistics is to use GitHub insights and look at the commutes that were done against the GitHub. And even if the number of contributors, I think it's around 50, something like that. But that's only to the number of commutes and merges to the master branch, not other branches. So yeah, go to the insights. Yeah, that's a very good, I would say the contributors, go to the contributors to the left navigation panel. Yeah, contributors. So you can see the statistics. So the project was actively, is actively contributing with different commits and so on. So I think this is a very good statistics and metrics we can look at. And you can see diversity, well, me from DTC, Nikia from Fujitsu, Alturas below. Well, it's not specifically by the company because we know the GitHub, so you cannot go to the company email. But I think this is a very good metrics to look at and see how people, yeah, the clones, this is very important. People are using, and you can see unique cloners and then the visitors, they're very good statistics to have.  I don't want to dig into this further now. I think this touches on one point that Hart brought up in his email, which is there are different ways we can measure diversity, contribution and all that and a take in general. And so I think we can talk about that in that context and the discussions is related to these issues. I'd like to spend the last five minutes we have on starting discussion on a point that I thought was very interesting that Daniel raised regarding the DCO and the use of pseudonyms. And I don't expect us to make any decision on this now and the issue was just brought up and I'm just hoping we can prime the pump so we can have a constructive, productive discussion offline so that we can move further on this issue. But essentially this has to do with this, the question of, I mean, the situation that we all face is that a lot of people use obscure ideas to contribute to open source. And it's, what is acceptable and what's not? How much do we need to know about people's identity? And so if you can click on this, right, open the issue. I saw Chris commented already a little bit and there's a few comments. I don't know how many people had the chance to look at it but I think it's a very serious issue. And we've raised that, we have faced that issue also when it comes to even building the list of contributors for the election, right? We have been facing this. The staff says, well, we have people we don't know who they are. We don't even have it valued in their address. So this touches on this issue. Fundamentally it's like, how much do we need to require people to reveal to be able to participate in our community? Well, if you're asserting that there's some legal basis and legal clearance of the code, which we do assert, then you have a lot more requirements than you do on the normal side, right? Yeah, so how far do you, so what's your opinion? How far do you think it's a requirement? I think you have to know that, I mean, you have a lot of options in there.  I mean, I'm just not sure why you wouldn't use real, I mean, why people have an issue in there. I mean, that's why you come here, right? That's why you come into a place that's supposed to provide governance of code. Right. I mean, the context here we have, and the whole purpose of the DCO is basically to assert that you have the privilege and the right to submit the code that you're submitting and that you're abiding by, you know, whatever the rules of the license are, in the case of Apache, that means that any intellectual property that you may claim on behalf of the code you're submitting needs to be granted a license to anybody who uses that code. So, and the thing of it is that it's Hyperledger Board decided tomorrow to say, well, we're gonna change from Apache and we're gonna use GPL or something. I'm not saying that that's gonna happen, but if we did, what we would have to do is we have to track down everybody that's contributed code and get them to agree. This is, and Bob, I think was on the call, you know, he tried to do this for Ethereum C++ client and, you know, fell a couple short because, well, that was for different reasons, but basically you need to be able to track everybody down and get their permission if you're gonna do something like make a license change. If we wanted to go from Apache two to three, we would still have to do that, right? So, I think it is important that the email address be something that you can reach. Another problem that we have is that a lot of people are making commits and putting essentially a dev null mailing address, you know, like something that's behind a firewall or something that's on their laptop or whatever. It just, it's not a real address, but it looks like one. And I think that's where we have the problem.  We don't know who they are. It's not a matter of who you work for necessarily it's really much more about being able to contact you if we need to do something from a licensing perspective. Yeah. So, Dano, you raised this issue and when I read your message, thank you for doing this, by the way. You know, it wasn't clear to me whether you had any opinions one way or another because you put up all these different possibilities with a big range, you know, under the full spectrum. So, I do have opinions on how it should work, but I wanted to gauge the opinion of the, of the TSC to see if there's any existing policy. I agree that DCOs provides traceability to contact them, but if you read further down in the background, there's a couple of other issues. What do people operate under real sounding names? They're actually pseudonyms. And a different issue is can we accept maintainers who operate under pseudonyms? I think the second one is no. They could publicly have a pseudonym, but they would need to unmask to the TSC for maintenance. But for contribution, I think at some level, whoever's accepting it probably needs to know who it is. And I don't think we need to require them to unmask to anyone, but if you're committing someone's pseudonymous commit, you should know who they are. And I think that's a duty that a maintainer would have is if they're accepting pseudonymous contributions that they have as much level of certainty as if they signed the DCO themselves, that the contribution is legit. All right, so we're out of time, but thank you for bringing this up. I think it's definitely worth chewing a little bit more on this and trying to come up with some rules that we could write down and live by moving forward. I mean, to answer the basic question is like, we don't have anything written down on this as far as I know. So it's a good opportunity to do so. All right, so we're out of time. We can make sure we do there or another, so we should step back and make sure, what do we believe that the membership of Hyperledger and the people who are using Hyperledger projects actually believe that they're getting, right? Obviously they have to do their own diligence and accountability, but because I think that's the kind of key, right? I think that's that part of the, you know, the- I agree. So I encourage people who have an opinion to follow up on the wiki and please come up with proposals if people have specific ideas of what the answer should be. Raising questions is useful, but proposing answers is even better. So- And I know we're out of time, but maybe this is something that we should be asking the legal counsel, you know, whether that's Mike or- Yeah, that's what I was actually looking at. Maybe we should be asking legal what the legal deal is, because, I mean, the Linux kernel has been operating under the DCO since forever, and I'm sure they've been through this discussion. Yeah, that's a good point. I won't follow up with the staff. This team can answer right away or maybe Mike. Yeah. No, that's a good point. I will follow up with the staff and try to find out whether they have any answers to contribute. Okay, I don't want to drag this on any further. Thank you all for joining today. I think we had a good discussion. I look forward to continuing next week.


My goals were to get through it and to leave the HCC in a better place and I think that came to fruition. When Alex Wilfert first ran for president, his big campaign promise was students first. Now, as he prepares to graduate, he looks back on how he fulfilled that promise. Always trying to make sure that you were listening and interacting with communities, community leaders, folks here in the HCC and administration, trying to kind of get something done after that and making sure that the concerns that students are bringing up are things that you're able to actually follow through with and address. One key issue, him, his office and other senators addressed, came from the need of community leaders. The result? A multicultural grant. So every year $75,000 will be allocated from the office of the president to communities of color for programming around cultural organization. I was really proud of that and actually being able to see it come into fruition by attending all of these events, things like PCN, Filipino Cultural Night, VSA, you know, Arab Student Union. It was great to be at all these events and to know that you were able to kind of help. As he weighs moving to New York for a century or working on a 2020 campaign, advocacy for communities in need is something Wilfert hopes to continue to strive for. See I'm definitely definitely want to make an impact and keep helping helping folks. I think that's what I really is my passion and also just the way you know state of American society right now. I think we need more advocates so that's that's my goal. When asked how he hopes students remember him, I'd hope they remember he as a as a as a good advocate, as a good leader and someone who really tried to do the best by his communities and by the students on this campus. As his term comes to a close, Wilfert is left with one thing, gratitude. Thank you for letting me be your president this year. I hope I made you proud. I hope that you felt like we made an impact here. For Cal TV News, I'm Laylee Ipsa.


The 2014 Wounded Warrior Team Navy Trials kick off today at Naval Station Norfolk. Approximately 70 seriously wounded, ill and injured sailors and coast guardsmen are competing for a spot on this year's Navy Wounded Warrior Team. Athletes face off in archery, cycling, track and field, swimming, shooting, sitting volleyball and wheelchair basketball. Visit the Safe Harbor website for a schedule of events and see how Safe Harbor supports our Wounded Warriors. SecNAV formally named the amphibious assault ship USS Tripoli at Marine Barracks Washington May 30th. SecNAV's wife, Lynn Mabus, is the ship's sponsor. The ship's name commemorates the capture of Dernalibia in 1805 and is memorialized in the Marine's Hymn with a line to the shores of Tripoli. Read more about these stories at Navy.mil. From all hands, thanks for watching.


Welcome to this explainer video on the SDM32 Nucleo Motor Control Expansion Board using Arm Embed Environment. This expansion board enables you to drive one high-power bipolar stepper motor as required by the most demanding motor control applications. We are going to explain how to get your application running in the Arm Embed Environment. The first half of the video will focus on the software setup and the second half will detail the hardware functionality available. Now, connect the high-voltage stepper motor to the expansion board. Then, connect a voltage supply. In this case, we use a 12-volt supply. Then, you can connect the SDM32 Nucleo Board to a PC using a mini USB cable. And then, you are ready to power on! Now, connect to the Arm developer.embed.org website and log in with your credentials. Click on Hardware, then Components, and select Motor under the actuators category. Click on X-Nucleo IHM-03A1 high-power stepper motor driver and find the Hello World IHM-03A1 application example on the next page, then import it into the online compiler. Open the main program and choose the desired target platform. Add a new one if needed. At this point, build the application and download it on the Nucleo Board. After completing the download, or when pressing the black button on the Nucleo Board, the application will reset and start. This simple application shows how to run a stepper motor forward and backward, setting the torque regulation current, storing the current position as a reference, home position, and returning to it, and playing with the microsteps and the speed. And now, some details about the SDM32 Nucleo high-power stepper motor expansion board. It includes a fully integrated microstepping motor driver, the PowerStep01, and can actually be stacked up to three times to drive three stepper motors with a single SDM32 Nucleo board. At www.st.com-x-nucleo under the reference X-Nucleo IHM-03A1, you can find user manuals, quick start guides, bill of materials, and lots of other detailed documentation to help you on your way to building your application.


company will benefit or you won't get any trouble for the most part when it comes to open source I thought there was an awesome code that I just put my name under in case someone wants to use it so thank you very much this is my talk if you have any questions please yes so when I deal with a language like that I try to enforce virginity so usually although it is not inherently available when you import a package it will always grab the latest however there is a mechanism where you can specify a specific version and generally when you work in a big enterprise in a big company you always try to force specific versioning practices, you always want to know whatever is coming in the pipe it will always come out the same way each and every time and generally in big organizations they have their own repositories internally so whatever versioning happens in the outside world they are always bound to the versions they have internally but it is always good practice to go specifically with the inside versions that's it because when you package your application you package it unless you are using Docker or something like that you package it on multiple layers and once you package it for production it is generally frozen at that state so when you are in you do your dev and you keep upgrading as you go along but once you reach the staging environment you are kind of stable with the versioning generally you are not going to upgrade a library once you are in stage so that is a good time to do that process and the time it takes to soak your application in stage is long enough for the process to go through by that time you pretty much know what the version is ok well thank you everyone for attending I hope you enjoyed the talk I know I did thank you very much you know well Shaden like my daughter was like a 10 minutes to start time and she is bored already were you bored honey ok I am sorry I will make it up to you at least you are honest about it thank you are your daughters coming are your daughters coming oh come on they don't need a pass to come I just cleaned up awesome