NavTalks
From Navigators
(Difference between revisions)
Line 2: | Line 2: | ||
<p><i>Leave mouse over title's presentation to read the abstract.</i></p> | <p><i>Leave mouse over title's presentation to read the abstract.</i></p> | ||
+ | <!--<span title=""></span>--> | ||
<div style="background:#FFFFFF; border:1px solid #FFFFFF; padding:5px 10px"> | <div style="background:#FFFFFF; border:1px solid #FFFFFF; padding:5px 10px"> | ||
Line 9: | Line 10: | ||
<td style="width:10%">20 September</td> | <td style="width:10%">20 September</td> | ||
<td style="width:30%">Alysson Bessani</td> | <td style="width:30%">Alysson Bessani</td> | ||
- | <td style="width:50%">SMaRtChain: A Principled Design for a New Generation of Blockchains</td> | + | <td style="width:50%"><span title="The blockchain has emerged as a disruptive paradigm to build decentralized transactional applications such as cryptocurrencies. The core of the technology is the consensus algorithm used to order blocks of transactions in a Byzantine fault-tolerant (BFT) way. There are two basic classes of such algorithms: Nakamoto consensus (employed in Bitcoin and other permissionless systems), which requires peers to solve a cryptographic puzzle to propose new blocks and eventually converge to a single chain; and “traditional” BFT consensus (used in permissioned systems), which employs well-known protocols for reaching agreement in a closed set of known processes. The former scales to 10000s of nodes but can process only a few transactions/s with a latency of hours, while the latter performs much better, but only with a few dozens of nodes. Recently, many hybrid consensus protocols have been proposed. They merge these two classes to achieve both scalability and performance. Although promising, they are still subject to limitations coming from their building blocks (e.g., high latency and power consumption). SMaRtChain aims to devise a set of radically different consensus protocols for both permissioned and permissionless blockchains. First, we plan to extend the Consensus with Unknown Participants paradigm to adapt it for open blockchains, aiming to overcome the limitations described above. Second, we want to design new scalable and high-performance BFT consensus algorithms based on solid theoretical building blocks for 1000s of nodes (enough for hybrid and permissioned blockchains) and capable of processing 1000s of transactions/s with sub-second latency. We will implement and integrate these contributions into existing open-source blockchain platforms (e.g., Fabric, Corda) for maximum impact. Finally, we will investigate and address the limitations of existing blockchains to support applications requiring big data, machine learning, and integration with the internet of things.">SMaRtChain: A Principled Design for a New Generation of Blockchains</span></td> |
<td style="width:10%"> </td> | <td style="width:10%"> </td> | ||
</tr> | </tr> | ||
Line 15: | Line 16: | ||
<td style="width:10%">20 September</td> | <td style="width:10%">20 September</td> | ||
<td style="width:30%">Rui Miguel</td> | <td style="width:30%">Rui Miguel</td> | ||
- | <td style="width:50%">Named Data Networking with Programmable Switches</td> | + | <td style="width:50%"><span title="The Internet today is mainly used for distributing content, in a fundamental departure from its original goal of enabling communication between endpoints. As a response to this change, Named Data Networking (NDN) is a new architecture rooted on the concept of naming data, in contrast to the original paradigm based on naming hosts. This radical architectural shift results in packet processing in NDN to differ substantially from IP. As a consequence, current network equipment cannot be seamlessly extended to offer NDN data-plane functions. To address this challenge, available NDN router solutions are usually software-based, and even the highly-optimised designs tailored to specific hardware platforms present limited performance, hindering adoption. In addition, these tailor-made solutions are hardly reusable in research and production networks. The emergence of programmable switching chips and of languages to program them, like P4, brings hope for the state of affairs to change. In this presentation, we present the design of an NDN router written in P4. We improve over the state-of-the-art solution by extending the NDN functionality, and by addressing its scalability limitations. A preliminary evaluation of our open-source solution running on a software target demonstrates its feasibility. ">Named Data Networking with Programmable Switches</span></td> |
<td style="width:10%"> </td> | <td style="width:10%"> </td> | ||
</tr> | </tr> | ||
Line 27: | Line 28: | ||
<td style="width:10%">4 October</td> | <td style="width:10%">4 October</td> | ||
<td style="width:30%">Bruno Vavala (Research Scientist in Intel Labs) </td> | <td style="width:30%">Bruno Vavala (Research Scientist in Intel Labs) </td> | ||
- | <td style="width:50%">Private Data Objects</td> | + | <td style="width:50%"><span title="I will present Private Data Objects (PDOs), a technology that enables mutually untrusted parties to run smart contracts over private data. PDOs result from the integration of a distributed ledger and Intel Software Guard Extensions (SGX). In particular, contracts run off-ledger in secure enclaves using Intel SGX, which preserves data confidentiality, execution integrity and enforces data access policies (as opposed to raw data access). A distributed ledger verifies and records transactions produced by PDOs, in order to provide a single authoritative instance of such objects. This allows contracting parties to retrieve and check data related to contract and enclave instances, as well as to serialize and commit contract state updates. The design and the development of PDOs is an ongoing research effort, and open source code is available and hosted by Hyperledger Labs (Linux Foundation).">Private Data Objects</span></td> |
<td style="width:10%"> </td> | <td style="width:10%"> </td> | ||
</tr> | </tr> | ||
Line 33: | Line 34: | ||
<td style="width:10%">4 October</td> | <td style="width:10%">4 October</td> | ||
<td style="width:30%"> Marcus Völp (Research Scientist, CritiX, SnT, Univ. of Luxembourg) </td> | <td style="width:30%"> Marcus Völp (Research Scientist, CritiX, SnT, Univ. of Luxembourg) </td> | ||
- | <td style="width:50%">Reflective Consensus</td> | + | <td style="width:50%"><span title="As you are well aware, many practical concerns in systems aiming at Byzantine fault and intrusion tolerance require reaching consensus in difficult situations. For example, to remain exhaustion safe, replacing permanently damaged replicas requires relocating the replicated functionality to a fresh set of spares, necessitating conensus on the new group of active replicas. While group membership protocols exists for this task, we are also aware of their limitations (faults in the adaptation infrastructure (recurring the problem in the servers implementing it), operation modes that cannot reach consensus (aka Cheap / ReBFT minimal mode), etc.) that make it extremely difficult (if not impossible) to perform these reconfigurations in a reliable manner. In this talk, I would like to give you an overview over some of the current (unsolved) research problems we work on in CritiX and which I would like to discuss with you while here. I would like to share my view on our hinge that in some of the above settings, there is still hidden an impossibility result, possibly rendering CheapBFT (or at least generalizations of it to arbitrary quorums) incorrect, but motivating a novel design principle, which we call reflective consensus: Rather than solving the difficult, but naturally arising consensus problem (e.g., consensus on group membership in case of exhaustion failure due to an increasing threat level), we reflect consensus to the same set of replicas where it will occur, but in a simpler version that is possibly even executed at a different time (e.g., proactively when the system is not yet exhaustion failed). ">Reflective Consensus</span></td> |
<td style="width:10%"> </td> | <td style="width:10%"> </td> | ||
</tr> | </tr> | ||
Line 45: | Line 46: | ||
</div> | </div> | ||
- | + | ||
<div style="background:#FFFFFF; border:1px solid #FFFFFF; padding:5px 10px"> | <div style="background:#FFFFFF; border:1px solid #FFFFFF; padding:5px 10px"> |
Revision as of 11:37, 12 November 2018
The Navtalks is a series of informal talks given by Navigators members or some special guests about every two-weeks at Ciências, ULisboa.
Leave mouse over title's presentation to read the abstract.
Contents |
September 2018
20 September | Alysson Bessani | SMaRtChain: A Principled Design for a New Generation of Blockchains | |
20 September | Rui Miguel | Named Data Networking with Programmable Switches |
October 2018
4 October | Bruno Vavala (Research Scientist in Intel Labs) | Private Data Objects | |
4 October | Marcus Völp (Research Scientist, CritiX, SnT, Univ. of Luxembourg) | Reflective Consensus | |
18 October | Yair Amir (Professor, Johns Hopkins University) | Timely, Reliable, and Cost-Effective Internet Transport Service using Structured Overlay Networks |
November 2018
13/11 | Salvatore Signorello | The Past, the Present and some Future of Interest Flooding Attacks in Named-Data Networking | |
13/11 | Tiago Oliveira | Vawlt - Privacy-Centered Cloud Storage | |
27/11 | Nuno Neves | ||
27/11 | Ricardo Mendes |
December 2018
11/12 | António Casimiro | |||
11/12 | Carlos Nascimento |
January 2019
15/01 | Fernando Alves | ||
15/01 | Ibéria Medeiros | ||
29/01 | Fernando Ramos | ||
29/01 | Miguel Garcia |
February 2019
19/02 | Ana Fidalgo | ||
19/02 | João Sousa |
March 2019
12/03 | Pedro Gaspar | ||
12/03 | Ricardo Morgado | ||
26/03 | André Oliveira | ||
26/03 | Nuno Dionísio |
April 2019
09/04 | Adriano Serckumecka | ||
09/04 | Tulio Ribeiro | ||
30/04 | Miguel Moreira | ||
30/04 | Pedro Ferreira |
May 2019
14/05 | Diogo Gonçalves | ||
14/05 | Vinicius Cogo | ||
28/05 | Francisco Araújo | ||
28/05 | Miguel Matos |
June 2019
11/06 | Eric Vial | ||
11/06 | Robin Vassantlal | ||
25/06 | João Pinto | ||
25/06 | Tiago Correia |